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A  SOFTWARE  INTERFACE  FOR  THE 
ARL  WIND  TUNNEL  DATA  ACQUISTION  SYSTEM 


by 

B.D.  FAKLIE 
S.S.W.  LAM 


SUMMARY 


A  software  interface  for  the  data  acquisition  system  has  been  developed  on  a  MicroVAX  II 
computer  for  the  Transonic  and  Low  Speed  wind  tunnels  at  ARL.  The  software  is  responsible 
for  handling  instrumentation  control  and  data  transfer  requests  between  the  data  acquisition 
software  and  the  parallel  data  bus  via  a  DRVll  parallel  HO  interface  adapter.  Access  to  the 
DRV II  registers  is  effected  by  direct  rrutpping  of  the  Q22-Bus  HO  page  to  program 
variables,  giving  fast  and  efficient  transfer  of  data  to  and  from  the  parallel  data  bus.  Up  to 
five  processes  may  access  the  parallel  data  bus  at  one  time  via  this  software  interface  thus 
allowing  great  flexibility  in  the  development  of  data  acquisition  software.  This  report  details 
the  necessary  programming  steps  which  must  be  included  in  data  acquisition  software  to 
access  the  parallel  data  bus  via  the  software  interface. 
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1  INTRODUCTION 


The  use  of  computers  for  data  acquisition  and  analysis  in  wind  tunnels  at  the  Aero¬ 
nautical  Research  Laboratory  (ARL)  began  in  the  early  1960s.  The  early  Transonic 
Wind  Tunnel  (VPT)  instrumentation  was  built  around  a  Digital  Equipment  Corpora¬ 
tion  (DEC^)  PDP^-8/I  computer  and  automated  much  of  the  testing  procedure  and 
data  analysis.  This  system  was  in  operation  from  1967  until  the  late  1980s  by  which 
time  the  PDP-8/I  computer  had  well  and  truly  reached  the  end  of  its  life.  It  was  then 
replaced  by  a  DEC  MicroVAX^II  micro- computer.  Much  of  the  instrumentation  that 
was  built  around  the  PDP-8/I  was  also  replaced. 

In  the  Subsonic  Wind  Tunnel  (LSWT),  up  until  the  1960s  analysis  of  data  was  carried 
out  in  an  off-line  batch  operation  on  an  external  computer.  In  the  early  1970s  the  first 
on-line  data  acqtiisition  system  was  installed,  which  collected  data  &om  selected  data 
sources  in  a  pre-arranged  sequence.  The  data  was  subsequently  analysed  off-line  on 
the  central  site  computer.  Later,  a  serial  line  connecting  the  system  to  the  central  site 
computer  allowed  data  to  be  processed  in  ^‘real-time”  and  the  results  of  the  test  dis¬ 
played  on  a  terminal  screen  almost  immediately  after  the  data  had  been  collected.  In 
1982,  a  dedicated  DEC  PDP-11/44  mini-computer  was  installed  for  the  sole  purpose 
of  wind  tunnel  data  acquisition  and  processing,  and  tunnel  control.  Comprehensive 
software  has  been  written  and  developed  over  the  years  to  take  advantage  of  the  com¬ 
puting  power  available  on  this  dedicated  system.  Up  until  the  late  1980s  data  were, 
however,  still  being  collected  via  a  relatively  slow  and  cumbersome  “serializer”  which 
had  become  outdated  and  umeliable. 

To  maintmn  the  productivity  and  quality  of  the  work  that  has  been  carried  out  in 
these  wind  tunnels,  a  new  data  acquisition  system  based  on  microprocessor  technology 
was  designed  at  ARL  and  installed  in  both  tunnels.  The  new  system  comprises  of 
several  microprocessor  based  instrumentation  modules  (slave  modules)  connected  to  a 
dedicated  master  (host)  computer  via  a  bi-directional  differential  parallel  data  bus  also 
developed  at  ARL  [1].  Reference  [1]  describes  this  system  and  reasons  for  selecting 
a  master  slave  system  with  the  intelligence  distributed  across  the  bus.  This  report 
describes  the  software  that  provides  an  interface  between  the  parallel  data  bus  and 
the  data  acquisition  programs  which  run  on  the  master  computer.  The  software  is 
written  in  VAX^  FORTRAN  but  the  ideas  and  logic  could  readily  be  adopted  to  other 
high  level  computer  languages. 

2  THE  HARDWARE  INTERFACE 

Communication  between  the  Micro  VAX  II  computer  and  the  tunnel  instrumentation 
modules  is  provided  by  a  bi-directional  differential  parallel  (BDF)  bus  system  with 
appropriate  interfaces  as  shown  in  Figure  1.  The  BDP  data  bus  is  a  16-bit  wide  bus 
that  provides  input,  output,  control  and  addressing  functions.  It  operates  in  a  mas¬ 
ter/slave  format  in  which  the  master  initiates  all  traffic  on  the  address  bus.  It  allows 
input  and  output  to  be  sent  to  or  received  from  any  individual  tunnel  instrumenta¬ 
tion  module  (slave),  in  any  order,  with  the  timing  controlled  by  the  Micro  VAX  II 
computer  (master).  The  slave  modules  cannot  address  the  master,  which  eliminates 
the  possibility  of  bus  hang-ups  caused  by  two  or  more  modules  activating  the  bus 
simultaneously.  However,  the  slaves  can  signal  the  master,  requesting  its  attention 
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via  a  common  erroi/flag  line.  The  master’s  attention  is  requested  to  warn  of  an  error, 
such  as  invalid  data,  to  indicate  that  data  gathering  has  been  completed  or  that  a 
control  function  setting  has  been  fiaalized. 

The  parallel  input /output  interface  between  the  Q22-Bus^  of  the  Micro  VAX  n  com¬ 
puter  and  the  wind  tunnel  data  bus  is  provided  by  a  DEC  DRVll  General  Device 
Interface  Adapter.  There  are  several  variants  of  the  DRVll  Adapter  avmlable  on  the 
Micro  VAX  n  computer.  The  one  used  here  is  the  Q22-Bus  equivalent  of  the  UNIBUS^ 
DRll-C  interface  adapter,  designated  as  DEC  module  number  M7941.  There  is,  how¬ 
ever,  a  design  fault  in  the  circuit  board  and  modifications  must  be  made,  which  are 
detailed  in  Appendix  A.  The  DRVll  is  a  general-purpose  digital  interface  which 
provides  16  input  and  16  output  lines  (for  handling  16-bit  parallel  data),  and  8  con¬ 
trol  lines  (for  transferring  control  and  status  information)  to  transistor-transistor 
logic  (TTL)  compatible  external  devices.  These  input/output  and  control  lines  are 
converted  to  a  bi-directional  differential  parallel  bus  via  a  single  self-contained  card 
interface  —  the  DRVll  Bus  Interface  card,  also  developed  at  ARL  [1].  Through  this 
hardware  arrangement  the  Micro  VAX  11  computer  can  communicate  with  the  slave 
modules  at  a  rate  greater  than  1800  16-bit  data  words  per  second  [1]. 


3  A  DRVll  “DEVICE  DRIVER” 

An  interface  adapter  attached  to  the  Q22-Bus  of  a  Micro  VAX  11  is  usually  accessed 
from  a  computer  program  via  a  device  driver  that  is  part  of  the  VMS*  operating 
system.  However,  the  DRVll  is  not  supported  by  VMS,  and  hence  a  device  driver  is 
not  available.  A  different  approach  must  therefore  be  employed  to  effect  the  transfer 
of  data  and  controls  from  user  written  programs  to  the  DRVll  interface  adapter. 

The  DRVll  has  three  registers  for  control  and  data  transfer  [2]; 

•  the  control  and  status  register  (CSR) 

•  the  output  buffer 

•  the  input  buffer. 

These  registers  may  be  accessed  from  within  a  computer  program  by  mapping  the 
MicroVAX  Q22-Bus  input/output  (I/O)  page^,  which  contains  the  addresses  of  the 
device  registers  above,  to  variables  appropriately  defined  in  the  program.  Values  as¬ 
signed  to  these  variables  are  written  directly  into  the  respective  registers  and  data 
received  by  the  input  btiffer  may  be  read  directly  from  the  variable  mapped  to  it.  This 
technique  of  accessing  the  registers  of  a  device  directly  is  very  efficient  [3],  because  it 
by-passes  the  VMS  operating  system’s  optimization  and  resource  management  pro¬ 
cesses.  However,  the  techmque  is  also  dangerous  if  not  used  correctly,  as  it  also 
by-passes  the  normal  checking  and  protection  procedures  of  the  operating  system. 

The  two  interrupt  vectors  of  the  DRVll  interface  may  be  connected  to  a  process^ 
by  a  simple  device  handler,  COHIHTERR,  through  the  VMS  STSGEN  facility  [4].  The 

*Q33-Bas,  UNIBUS  and  VMS  we  tegiatered  tredesawks  of  Digital  Equipment  Coipotation 
*A  page  is  a  set  of  $12  contiguous  byte  locations  used  as  the  nnit  of  memory  mapping  and 
protection. 

^VMS  refers  to  any  task  under  the  control  of  the  operating  system,  including  any  routines  that 
may  be  executed  as  part  of  the  running  a  scheduled  job  as  a  process. 
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parallel  data  bus  uses  one  interrupt  to  indicate  to  the  master  that  data  are  ready, 
and  the  other  to  notify  the  master  of  any  error  detected  in  the  instrumentation. 

3.1  Mapping  The  Input/Ouiput  Page 

To  gain  access  to  the  I/O  page  (or  for  any  page  of  physical  memory)  a  process  must 
map  the  page  into  its  virtual  address  space.  In  the  present  case,  the  page  of  interest  is 
that  containing  the  DRVll  registers.  The  VMS  operating  system  provides  a  system 
service  routine  SYSiCRMPSC  (create  and  map  section)  to  perform  the  mapping  of  I/O 
space  to  a  process’s  memory.  This  routine  is  called  as  follows: 

status  =  SYS$CRMPSC( [inadr] , [ratads] . [acmode] . [flags] , [gsnam] , 

1  [idont] , [ralpag] , [chan] , [pagecnt] , [vbn] , [prot] , [pf c] ) 

where  status  is  an  INTEGER'^4  variable  returned  by  the  routine  to  indicate  the  status 
of  the  operation.  According  to  the  convention  used  in  the  MicroVMS  Programmer’s 
Manual  [5],  items  enclosed  in  square  brackets  are  optional.  The  parameters  relpag, 
chan  and  pf  c  are  not  relevant  to  mapping  the  I/O  space  and  can  be  left  blank.  The 
other  arguments  have  the  following  meaning: 

inadr  —  An  array  of  two  longwords®  containing  the  addresses  of  the  beginning  and 
end  of  the  region  in  virtual  memory  to  which  the  I/O  page  is  to  be  mapped. 
Thus,  to  map  a  single  page  of  I/O  space  to  an  array  variable,  iopage,  the 
following  code  fragment  may  be  used. 

1NTEGER*2  iopaga (0 : 2SS) 

INTEGER*4  inadr (2) 

inadr(l)  =  7.L0C  C  iopage(O)  ) 
inadr(2)  =  )U.0C  (  iopage(25S)  )  ■•■  1 

The  variable  iopage  to  which  the  I/O  page  will  be  mapped  is  256  words  long 
since  there  are  512  bytes  in  each  page,  inadr  (1)  is  the  address  of  the  beginning 
of  the  region  and  inadr(2)  is  set  to  the  address  of  iopage(255)  plus  one,  so 
that  it  contains  the  last  byte  of  the  region. 

rotadr  —  An  array  of  two  longwords  which  on  return  from  the  routine  SYSiCRMSPC 
will  contain  the  addresses  of  the  beginning  and  the  end  of  the  region  of  virtual 
memory  that  the  I/O  page  was  actually  mapped  to.  Note  that  if  ratadr(l)  ^ 
inadr(l)  or  r«tadr(2)  ^  inadr(2),  then  an  error  has  occurred,  usually  due 
to  mis-specification  of  one  or  more  parameters.  If  the  mapping  has  not  been 
done  at  all,  both  values  in  retadr  are  returned  as  -1. 

acmoda  —  This  parameter  specifies  the  access  mode  to  be  applied  to  the  mapped 
region.  It  is  optional  and  is  omitted  in  the  present  case.  The  access  mode  then 
defaults  to  that  of  the  calling  process. 

flags  —  A  longword  containing  a  mask  which  determines  the  characteristics  of  the 
mapped  section.  When  mapping  the  I/O  page,  flags  should  be  set  up  with  the 
following  code  fragment 

*  A  lonfword  is  a  data  unit  coRctpondiiic  to  4  bytes  of  memory,  usually  declared  as  an  inBfin*4 
variable  in  VAX  FORTRAN. 
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INCLUDE  *($SECDEF)»  j 

flags  =  SEC$M_PFKMAP  .OR.  SEC$M_WRT  | 

The  first  statement  includes  the  system  definition  library  module  containing  the  | 

definitions  of  the  bit  offsets  used  in  the  statement  following  to  set  the  variable  | 

flags.  SECIM.PFNMAP  indicates  that  the  mapping  should  be  done  via  page  frame  i 

number  ^  (see  the  description  of  vbn  below).  This  is  to  ensure  that  the  variables  t 

declared  in  a  FORTRAN  program  are  mapped  correctly  to  the  registers.  The  ' 

SEC|M_WRT  mask  bit  is  to  allow  the  mapped  section  to  have  read  and  write 
access. 

gsdnam  —  This  is  the  global  section  name  and  is  required  only  if  the  section  is  to  be  • 

accessed  globally.  It  is  not  used  in  the  present  case  and  is  left  blank. 

ident  —  An  argument  containing  match  information  for  global  sections.  It  only  s 

applies  to  global  sections. 

pagacnt  —  A  longword  containing  the  number  of  pages  to  be  mapped.  It  is  equal  to 
1  in  the  present  case. 

vbn  —  A  long  word  containing  the  page  frame  number  (PFM)  of  the  memory  where  the 
mapped  section  begins.  The  PFN  of  any  physical  p^e  in  memory  is  contained 
in  bits  9  through  29  of  its  physical  address.  The  following  paragraph  shows  how 
the  PFK  of  the  I/O  page  containing  the  addresses  of  the  DRVll  registers  may 
be  obtained. 

The  address  of  the  control  and  status  register  (CSR)  of  the  DRVll  interface 
on  the  Q22-Bus  I/O  space  is  given  as  7676008  (3EF80i6)[4].  The  first  (least 
significant)  12  bits  of  this  address,  76008  (FSOie))  give  the  offset  address  in 
the  Q22*Bus  I/O  space.  This  address  must  be  added  to  the  physical  address 
at  the  beginning  of  the  Q22-Bus  I/O  space,  which  is  given  on  page  H-3  of 
Reference  [6]  as  20000000i6,  to  obtain  the  physical  address  of  the  DRVll  CSR, 
i.e.  20000F80i6.  Of  this  physical  address,  bits  9  to  23  are  the  PFN  and  bits  0  to 
8  are  the  byte  offset  within  the  page. 

20000r80i6  =  10  0900  0000  0000  0000  1111  1000  0000 2 

N  ■  ■  ■  I  — ■  ■  ■! 

PFN  Byte  offset 

=  10000716  =  180i6 

Therefore,  the  PFN  of  the  mapped  I/O  page  is  100007]6,  and  the  byte  offset  of 
the  DRVll  CSR  is  ISOi^. 

prot  —  A  longword  indicating  the  protection  mask  for  the  mapped  section.  This 
argument  may  be  omitted  and  defaults  to  read  and  write  access  for  all  users. 

Once  the  I/O  page  contidning  the  CSR  of  the  DRVll  interface  has  been  mapped, 
access  to  its  CSR  and  input  and  output  buffers  may  be  made  via  the  addresses  in 
the  process’s  virtual  memory  corresponcbng  to  these  register’s  offsets  relative  to  the 
beginning  of  the  mapped  page.  From  the  description  of  vbn  previously,  the  byte  offset 
of  the  DRVll  CSR  is  ISOie  =  394io.  The  word  (2  bytes)  offset  is  then  394/2  =  192. 

*?•(«  frame  munber  is  tbe  address  of  the  first  byte  of  a  pace  in  physical  memory. 
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Hence  the  CSR  may  be  accessed  via  iopage(192),  and  the  output  and  input  buffers 
become  iopage(193)  and  iopage(194)  respectively. 

Note  that  the  input  buffer  and  the  high  byte  of  the  CSR  of  the  DRVll  are  read 
only.  For  some  reason,  the  VMS  system  insists  that  the  input  buffer,  iopag«(194), 
be  equated  to  a  temporary  variable  before  being  output.  Otherwise  a  hardware  error 
(presumably  attempting  to  write  to  a  read-only  address)  occurs. 


3.2  Connecting  To  Interrupts 

Connecting  a  process  to  an  interrupt  vector  allows  the  process  to  receive  notification  of 
interrupts  from  some  hardware  device.  The  notification  may  be  via  any  combination 
of  the  following: — 

•  executing  a  user-supplied  interrupt-service  routine, 

•  setting  an  event  flag  in  the  calling  process,  or 

•  executing  an  Asynchronous  System  Tiap  (AST)  service  routine  that  gains  con¬ 
trol  following  the  interrupt. 

Before  using  the  connect- to- interrupt  system  service,  the  hardware  device  must  be 
configured  using  the  STSGEK  CONNECT  command  of  the  VMS  operating  system.  The 
following  dialogue  shows  the  procedure  to  configure  the  DRVll  as  device  OAAO  (OA 
is  the  standard  VMS  device  name  for  the  DRllC  interface  and  VMS  recognizes  the 
present  variant  of  DRVll  adapter  only  as  a  DRllC): — 

$  SET  DEFiOLT  SYSlSYSTEM 
$  RUN  SYSUEN 

SYSGEN>  CONNECT  OAAO  /ADAPTER=0  /CSR=X0767600  /VECTOR=X0300  - 
/DRIVER=CONINTERR 
SYSGEN>  EXIT 

$ 

The  components  of  this  command  have  the  following  meaning: — 

•  /ADAPTER^O  —  has  no  significance  on  the  Micro  VAX,  but  must  be  included  to 
conform  to  the  syntax  of  the  command. 

•  /CSR=/(0767600  —  specifies  the  Q22-Bus  address  of  the  DRVll  CSR. 

•  /VECTOR*X0300  —  specifies  the  interrupt  vector  table  address  of  interrupt  ‘A’ 
on  the  DRVll  adapter. 

•  /DRIVERsCONINTERR  —  connects  the  DRVll  to  a  skeletal  interrupt  driver. 

Note  that  all  addresses  (CSR  and  vector)  are  preceeded  by  XO  to  indicate  that  they 
are  octal  numbers.  This  SYSGEN  CONNECT  command  must  be  executed  every  time  the 
Micro  VAX  system  is  booted. 

The  previous  command  connects  only  one  of  the  two  interrupts  of  DRVll  to  the 
CONINTERR  driver.  To  connect  the  other  one,  the  following  command  must  also  be 
executed  in  SYSGEN. 
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SYSGEN>  CONNECT  OABO  /lDAPTEit=0  /CSR=y.0767600  /VECT0R=*/.03O4  - 
/DRIVER=CONINTERR 

where  3048  is  the  interrupt  vector  table  address  associated  with  DRVll  interrupt  ‘B’. 

Note  th'j.*  we  have  effectively  dehned  two  devices  —  OAAO:  and  OABO:  —  both 
accc.''''ug  the  same  physical  device  registers,  but  responding  to  different  interrupts. 
'■  errupt  ‘A’  is  used  by  the  parallel  data  bus  to  notify  the  MicroVAX  of  completion  of 
a  data  transfer.  Interrupt  ‘B’  is  used  to  warn  the  MicroVAX  of  some  error  conditions. 

At  run  time,  a  process  wishing  to  be  notified  of  interrupts  generated  by  the  DRVll 
must  first  assign  the  DRVll  devices  to  associate  a  VMS  channel  with  each  device. 
This  may  be  done  via  a  system  service  caU  such  as; — 

status  =  SYStASSIGN  (  ‘.OAAO:*,  chan,  .) 

where  chan  (declared  as  an  INTEGER*2  variable)  will  contain  the  value,  returned  by  the 
function  call,  of  the  chaimel  associated  with  the  DRVll  device  OAAO:.  Both  OAAO; 
and  OABO:  should  be  assigned  even  if  both  interrupts  are  not  to  be  used.  Assigning 
a  device  prevents  other  processes  &om  accessing  it,  and  hence  avoids  problems  with 
other  processes  altering  the  contents  of  the  DRVll  registers. 

The  process  can  now  be  connected  to  the  device  interrupt  via  a  call  to  the  system 
service  SYSSQIO  in  the  following  format; — 

status  «  SYSiqiO  (  [eln] ,  [chan3 ,  [Hiuic] ,  [losb] ,  [astadr] , 

1  CastpraJ  .  [pi]  ,  Cp2]  ,  Cp33  ,  Cp4]  ,  [pSj  .  [p6]  ) 

Two  calls  to  SYSiqiO,  one  for  each  interrupt  (device)  are  required.  AU  parameters 
except  the  p’s  have  standard  SYSIQIO  meanings  (see,  for  example,  the  chapter  on 
QIO  System  Service  in  Reference  [7]).  The  following  are  of  specific  interest: — 

chan  —  The  channel  number  obtained  from  a  previous  call  to  the  SYSlASSIGN  rou¬ 
tine. 

f  unc  —  A  word  contmning  the  I/O  function  code  —  when  connecting  to  an  interrupt, 
this  code  may  be  either  lOl.CONINTREAD  or  lOl.CONINTWRITE.  The  definitions 
of  these  fimction  codes  are  contained  in  the  system  definition  library  module 
IIODEF  which  is  included  in  the  program  source  in  the  following  manner: 

INCLUDE  ’(IIODEF)' 

or  the  codes  may  be  declared  as  EXTERNAL  by: 

EXTERNAL  lOl.CQINTVRITE,  lOl.COINTREAD 

pi  —  A  longword  containing  the  address  of  a  descriptor  for  a  buffer  containing  code 
and/or  data.  It  is  not  used  in  the  present  case. 

p2  —  A  longword  containing  the  address  of  an  entry  point  list  which  is  not  used  in 
the  present  case. 
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p3  —  A  longword  containing  fiags,  and  event  flag  number  specification.  The  flags 
are  used  to  describe  options  for  connect-to-interrupt  facility,  and  are  contained 
in  the  low-order  word.  The  high-order  word  contains  an  event  flag  number  to 
be  set  when  an  interrupt  occurs.  The  relevant  flags  required  in  the  present  case 
are: — 

CIN$M.£FN  (value  1)  indicates  that  an  event  flag  is  to  be  set  on  interrupt. 

CINIMJIEPEAT  (value  4)  indicates  that  the  process  should  be  left  connected  to 
the  interrupt  vector  until  the  coimect  is  cancelled  -  usually  by  the  process 
exiting. 

The  values  of  CIN|M_ . . .  are  obtained  from  the  macro  expansion  of  the  module 
tCINDEF  which  is  contained  in  the  VMS  system  macro  library  LIB. MLB  in  the 
SYSILIBRARY:  directory. 

The  only  reliable  way  to  set  up  this  long  word  is  to  set  up  a  FORTRAN 
record  which  maps  the  union  of  two  words  (INTEGER*2)  with  a  single  longword 
(IKTEGER*4)  as  follows 

STRUCTURE 

UNION 

MAP 

INTEGER  *  2  switches 
INTEGER  *  2  efnum 
END  MAP 
MAP 

INTEGER  *  4  llagword 
END  MAP 
END  UNION 
END  STRUCTURE 

A  variable  of  the  above  record  type  may  then  be  created  for  each  interrupt,  for 
example,  as: 

RECORD  /flag/  dra.flags,  drb.flags 
The  variable  ‘switches’  is  initialized  with  the  statements 

dra. f lags. switches  =  CIK$M_EFN  .OR.  CINIM.REPEAT 

drb. flags. switches  =  CINIM.EFN  .OR.  CINtN.REPEAT 

and  the  event  flag  numbers,  say  1  and  2,  are  specifled  as 

dra. f lags. ef SUB  =  1  !  for  event  flag  il 

drb. f lags. ef SUB  =  2  !  for  event  flag  *2 

p4  —  The  name  of  an  AST  routine  (which  must  be  declared  as  EXTERNAL)  to  be 
called  as  the  result  of  an  interrupt. 

p6  —  An  AST  parameter  to  be  passed  to  the  AST  routine  when  an  interrupt  occurs. 

p6  —  The  number  of  AST  control  blocks  to  be  pre-allocated.  This  is  not  required  in 
the  present  case. 
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Fin:  Uy,  to  allow  the  interrupt  signal  to  be  received  by  the  user  program,  the  interrupt 
enable  bits  (INT  ENB  A  and  INT  ENB  B,  see  Figure  2)  in  the  CSR  of  the  LRVll 
interface  adapter  must  be  set  to  1.  This  may  be  achieved  with  the  statements 

iopageCdr.csr)  =  IBSET  (  iopage(dr_csr) .  v.intenba  ) 
iopage(dr_csr)  =  IBSET  (  iopageCdr.csr),  v.intenbb  ) 

The  index  dr.csr  refers  to  the  location  of  DRVll  CSR  in  the  mapped  variable  array 
iopage.  The  bit  positions  of  INT  ENB  A  and  INT  ENB  B  in  the  CSR  are  v.intenba 
and  v.intenbb  respectively.  They  are  pre-defined  via  the  declarations 

INTEGER*2  dr.csr 

INTEGER*2  v.intenbb,  v.intenba 

PARAMETER  (  dr.csr  =  192,  v.intenbb  =  5,  v.intenba  =  6  ) 

Thus,  if  the  REQ  A  bit  is  asserted  while  INT  ENB  A  is  set  in  the  DRVll  CSR,  event 
flag  number  1  will  be  raised  (set).  If  the  REQ  B  bit  is  asserted  while  INT  ENB  B  is 
set,  event  flag  number  2  will  be  raised. 

3.3  Subroutine  DR.INIT 

The  above  procedures  for  setting  up  the  interface  between  a  process  and  the  DRVll 
at  run  time  have  been  combined  into  a  single  routine  DR.INIT.  This  routine  (see 
Appendix  D)  does  the  following: — 

1.  Maps  the  Q22-bus  I/O  page  containing  the  DRVll  registers  to  an  array  iopsige 
in  the  process’s  virtual  address  space. 

2.  Assigns  both  “devices”  and  obtains  their  chaimel  niimbers. 

3.  Connects  to  both  DRVll  device  interrupts.  Event  flag  number  1  is  associated 
with  the  DRVll  interrupt  A,  and  event  Cag  number  2  is  associated  with  DRVll 
interrupt  B. 

The  I/O  page  is  mapped  to  an  array  iopage  defined  as: — 

INTEGERe2  iopage(0:2S5) 

COMMON  /dr.common/iopage 

This  array,  and  hence  the  common  block  in  which  it  is  contained,  must  be  page 
aligned.  This  may  be  done  by  including  an  option  file  dr.link .  opt  with  any  LINK  [8] 
command  (qualified  with  the  LINK  switch  /OPT)  which  incorporates  dr.init.  The 
option  file  contains  the  line: 


PSECT.ATTR  *  dz.connion,  page 


4  SOFTWARE  I/O  INTERFACE  PROCESS  —  DIGIO 
4.1  Requirements  Of  The  I/O  Interface  Process 

Requests  for  data  transfers  to  or  from  the  parallel  bus  may  arise  imder  many  differ¬ 
ent  circumstances,  and  may  occur  as  the  result  of  the  operation  of  many  different 
processes.  As  the  data  acquisition  software  is  currently  set  up,  any  of  the  following 
processes  could  require  such  transfers: — 

1.  COM???  (the  many  variants  of  compute  sub-processes)  will  need  to  transfer  in¬ 
formation  to  the  bus  during  real-time  operations  (e.g.  set  point  Mach  number, 
Reynolds  number  length  scales  etc.)  ^md  will  obtain  raw  data  from  devices 
connected  to  the  data  bus  via  transfers  from  the  bus. 

2.  MON???  (the  many  variants  of  monitor  sub-processes)  will  need  to  acquire  data 
from  whatever  module  is  being  monitored.  The  frequency  with  which  MON??? 
processes  request  such  data  will  depend  on  what  tjrpe  of  operation  is  being 
monitored  (e.g.  when  monitoring  the  current  state  of  health  of  a  strain  gauge 
balance  more  frequent  requests  wiU  be  made  as  the  balance  and/or  model  max¬ 
imum  loads  are  approached). 

3.  TST???  (variants  of  a  general  process  used  to  test  individual  modules)  will  need 
to  obtain  data  from  the  particular  module  under  test  as  well  as  to  write  data 
to  that  module. 

To  coordinate  the  use  of  the  DRVll  interface  between  the  parallel  bus  and  the  Mi¬ 
cro  VAX,  all  input  and  output  of  data  to  or  from  the  parallel  data  bus  is  carried  out 
by  a  single  process  —  DIGIO.  This  process  will  be  run  (detached)  from  the  system 
startup  file  as: — 

%  RUN  /PR0CESS=DIG10  /ERR0R=DIGI0.ERR  /UIC= [200,0]  /DETACH  - 
lOISKl : [0ATAZN.EXEIDZGZ0.E2E 

and  hence  will  be  up  and  miming  whenever  the  MicroVAX  is  operational.  The 
qualifier  /ERROR^DZGZO.ERR  directs  any  run-time  error  messages  resulting  from  the 
execution  of  DIGZO  to  the  file  DIGZO.ERR.  The  /DIC^ [200,0]  qualifier  assigns  the 
DIGIO  process  a  user  identification  code  having  a  group  number  of  200,  which  is 
common  to  all  users  on  the  MicroVAX  system,  except  the  system  manager  and  a  few 
special  accounts.  This  is  to  ensure  that  DIGIO  can  communicate  with  other  processes 
run  by  other  users  (see  section  4.6).  IDZSKI:  [DATiZN.EXE]  is  the  directory  where 
DZGZO.EZE  is  located. 

Consideration  of  the  many  possible  processes  requiring  service  from  DIGIO  shows 
that  requests  for  data  transfers  from  some  processes  need  to  be  satisfied  more  quickly 
than  others.  For  example,  requests  for  the  real-time  COM???  processes  must  be  dealt 
with  immediately,  to  guarantee  that  raw  data  are  gathered  at  the  desired  moment  in 
time,  or  while  the  tunnel  conditions  remain  as  required.  On  the  other  hand,  it  matters 
little  if  the  data  requested  by  MON???,  for  example,  are  not  available  immediately.  In 
fact,  it  is  desirable  that  requests  already  in  progress  bom  processes  such  as  HON??? 
be  aborted  in  favour  of  a  request  from  COM???.  This  suggests  a  multi-level  priority 
system  in  which  a  low  priority  request  already  in  progress  makes  way  for  a  higher 
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priority  request,  and  that  low  priority  requests  queued  for  DIGIO  be  passed  over  in 
favour  of  requests  of  higher  priority.  Most,  if  not  all  the  features  of  an  ideal  system 
can  be  realized  with  a  two-level  —  high  and  low  —  priority  system. 

Implicit  in  the  above  discussion  is  the  provision  of  some  sort  of  queueing  system  for 
requests  to  DIGIO.  Requests  queued  to  DIGIO  would  need  to  include  the  following 
information: — 

1.  The  priority  of  the  request. 

2.  The  number  of  data  transfers  required  to  complete  this  request. 

3.  A  list  of  addresses  on  the  digital  data  bus  to,  or  from,  which  data  are  to  be 
transferred. 

4.  The  location  where  data  to  be  transferred  are  to  be  stored  or  found. 

Communication  between  DIGIO  and  processes  requesting  data  transfers  will  also  need 
to  include  some  mechanism  for  the  notification  of  errors.  In  general,  errors  will  be  of 
one  of  three  general  tjrpes: — 

1.  A  serious  error  may  be  signalled  by  the  parallel  data  bus,  indicating  some  sort 
of  fault  condition,  either  on  the  bus  or  in  the  interface,  from  which  recovery  is 
not  possible. 

2.  The  parallel  data  bus  may  signal  the  occurrence  of  a  recoverable  (non-fatal)  er¬ 
ror,  for  example  a  strain-gauge  amplifier  overloading.  Operations  may  continue 
following  such  errors  but  data  from  that  particular  module  on  the  bus  naay  be 
invalid. 

3.  A  low-priority  request  may  either  be  aborted  or  ignored  in  favour  of  a  higher 
priority  request.  In  either  case,  the  data  or  action  expected  by  the  requesting 
process  will  be  invalid,  and  the  process  must  be  notified  so  that  it  may  take  the 
appropriate  action  (in  many  cases  this  will  simply  be  to  requeue  the  request). 

The  operation  of  DIGIO  thus  requires  effective  communication  and  synchronization 
with  other  processes  wanting  to  access  the  DRV  11  interface,  or  for  that  matter, 
the  data  bus.  This  has  been  achieved  by  making  use  of  the  following  programming 
techniques  provided  by  VMS  and  VAX  FORTRAN; — 

1.  Mailboxes: —  These  are  channels  provided  by  VMS  for  interprocess  communi¬ 
cations  (see  section  3.4.2  of  Reference  5).  Messages  are  passed  into  mailboxes 
in  the  form  of  character  strings.  They  are  queued  within  the  mailbox  and  are 
read  by  the  destination  process  sequentially. 

2.  Installed  Common  Blocks: —  A  common  block  defined  in  a  FORTRAN  pro¬ 
gram  unit  may  be  installed  in  the  system  memory  as  a  shareable  image.  A 
program  wanting  access  to  tlus  common  block,  as  well  as  defining  and  declaring 
it  srithin  the  program  unit,  most  also  be  linked  to  this  image  (  see  section  4.4.4 
or  page  3-46  of  Reference  5). 

3.  Common  Event  Flags: —  Event  flags  are  used  to  signal  either  the  status 
(success  or  failure)  of  an  operation,  or  the  occurrence  of  a  particular  event. 
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They  may  be  waited  for  when  one  operation  must  be  completed  before  the  next 
one  can  continue,  or  they  may  be  checked  to  see  if  they  have  been  set  as  an 
indication  of  a  status  or  condition. 

4.2  The  DIGIO  MaUbox 

The  primary  means  of  communication  between  DIGIO  and  other  processes  is  a  queue 
containing  messages  requesting  DIGIO  to  carry  out  data  transfers.  This  queue  is 
reaUzed  as  a  VMS  mailbox  called  digio_mbox.  DIGIO  creates  this  mailbox  during 
its  initialization  phase  via  the  statement 

status  =  syslcrembx  (  X7iL(l). 

1  XVAL(mbox_chan) , 

2  mi.(2S6), 

3  XVAL(1024),  .  , 

4  ’digio_mbox’  ) 

where 

•  XVlL(l)  —  indicates  that  the  mailbox  is  permanent.  This  ensures  that  the 
mmlbox  lo^cal  name  is  entered  into  the  system  lo^cal  name  table  (rather  than 
the  process  logical  name  table)  making  it  available  to  all  other  processes. 

•  abox.chan  —  is  a  word  (INT£GER*2)  which  on  return  from  STSICRENBX  will 
cont^  the  channel  niunber  assigned  by  VMS  to  the  mailbox. 

•  XVAL(266)  —  indicates  that  the  length  of  any  message  sent  to  this  m^box  will 
not  exceed  256  bytes  (or  256  characters  in  VAX  FORTRAN). 

•  X7iL(1024)  —  specifies  the  size  (in  bytes)  of  a  buffer  set  aside  by  VMS  for 
temporarily  storing  queued  messages. 

•  ’digio_mbox'  —  is  the  name  given  to  the  mailbox. 

Any  process  wishing  to  queue  a  request  to  DIGIO  should  first  assign  a  channel  number 
to  the  mailbox  via  the  statement 

status  s  STS$iSSIGN  (  'digio_mbox' ,  digio_mbox_chan,  ,  ,  ) 

where  digio_Dbox_chan  (INTEGER«2)  is  the  returned  channel  number  and  is  used 
for  all  subsequent  transfers  of  messages  to  the  mailbox.  The  requesting  process  may 
then  send  a  message  to  digio_]nbox  via  the  system  service  routine  STSlQIOW  of  the 
following  form. 

status  «  STSlQIOW  (  ,  XTAl.(digio_abox_ehaB) , 

1  XTAL(mboz.«»ita..eode) ,  ,  ,  , 

2  XRBF(digio_aassags) , 

3  XTALClength)  ....  ) 

where 

•  digio_aboz_chan  —  is  the  channel  number  returned  by  STSliSSlGlI. 


11 


•  mboz_vxito_code  —  is  a  longword  (INTEGER*4)  containing  the  SYSfQIOW  func¬ 
tion  code  "wTite  to  a  mailbox”.  This  is  set  via 

mbox.vrite.code  =  IO$WRITEVBLK  .OR.  lOfM.NOW 

where  the  modifier  10$K.N0W  specifies  that  the  requesting  process  should  com¬ 
plete  the  function  call  now  rather  than  waiting  for  DIGIO  to  read  the  message, 
and  lOlWRITEVBLK  is  the  nuulbox  write  function.  All  the  10$ . . .  function  codes 
are  defined  in  the  system  definition  library  module  $I0DEF  of  the  system  library 
file  STS$LIBRiRT:FORSYSDEF.TLB.  The  $IOOEF  module  may  be  included  iu  the 
source  code  of  the  user  written  program  with  the  statement: — 

INCLODE  »(II0DEF)» 

•  digio_message  —  is  the  message  to  be  sent  to  DIGIO  (see  description  below). 

•  XViL  (length)  —  specifies  the  length  of  the  message. 

DIGIO  reads  messages  queued  in  digio_inbox  via  the  following  SYS$QI0W  call 

status  s  SYSIQIOW  (  ,  XViLCmbox.chan) . 

1  %VAI.(mboz.read_code) , 

2  mbox.iosb,  ,  , 

3  y.REF(abox_message) , 

4  y.VlL(256)  ) 

where  all  variables  are  similar  to  those  in  the  previous  SYS$QZ0W  caU  except  that  the 
function  code  is  given  by 

mbox.read.code  «  lOlRElDRBLK  .OR.  lOlM.NOU 

The  modifier  lOlM.NOW  specifies  that  the  SYSIQIOW  function  is  to  be  completed  nov 
rather  than  waiting  for  the  mailbox  to  contain  a  message.  The  input /output  status 
block  mbox.iosb  is  specified  by  the  structure: — 

STRUCTURE  /iostat.block/ 

IIfTEGER*2  iostat,  msg_longth 
lirrE6SR*4  ssndor.pid 
END  STRUCTURE 

RECORD  /iostat.block/  mbox.iosb 

In  addition  to  the  status  of  the  data  transfer,  DIGIO  can  also  obtsun  the  length  of 
the  message  read,  and  the  identity  of  the  process  which  sent  the  message  from  this 
status  block. 

4.S  The  DIGIO  Mailbox  Message 

Experiments  with  the  MicroVMS  system  have  invested  that  when  writing  to  or 
reading  from  a  nudlboz  a  few  long  messages  incur  significantly  less  overhead  than 
many  short  messages.  Hence,  if  a  process  requires  several  data  transfers,  it  is  better 
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to  combine  them  into  one  request,  rather  than  to  have  a  series  of  requests  each 
consisting  of  only  one  transfer.  This  arrangement  has  some  disadvantages,  the  most 
important  being  the  loss  of  a  one-to-one  relationship  between  bus  errors  and  data 
transfer  requests,  but  in  normal  circumstances  where  the  error  rate  is  low,  the  faster 
overall  rate  of  data  transfer  will  outweigh  this  disadvantage. 

Messages  sent  to  digio_Bboz  are  diaracter  variables  with  the  following  contents: — 

•  priority  —  indicates  the  priority  of  the  request  —  ‘H’  for  high,  ‘L’  for  low. 

•  requestor.indez  —  identifies  the  requesting  process. 

•  nuffl_addre8s«s  —  the  number  of  addresses  to  or  from  which  data  is  to  be  read 
or  written.  A  TnaTimnTn  of  50  addresses  (and  hence  data  transfers)  may  be 
included  in  each  request. 

•  addresses (i)  ,  i  «  1,  niim_addresses  —  indicates  the  actual  bus  addresses 
to  or  from  which  data  is  to  be  read  or  written. 

These  variables  are  encoded  into  the  character  array  variable  &boz_message  via  an 
internal  write  statement  with  a  format  of: — 

FOmT  (  Al,  IX.  II.  IX.  12.  <nuoi_addresses>(  IX.  14  )  ) 

All  information  needed  by  DIGIO  to  complete  the  transfers  is  contained  in  this 
message,  except  that  there  is  no  indication  of  the  direction  of  each  data  transfer, 
i.e.  whether  it  is  a  read  or  write,  as  this  is  encoded  directly  in  the  bus  address  for 
each  data  transfer.  The  parallel  data  bus  follows  the  convention  that  all  address  to 
which  data  may  be  written  are  odd  (least  significant  bit  set)  while  those  which  may  be 
read  are  even  (least  significant  bit  not  set).  Hence,  it  is  possible  to  include  a  mixture 
of  reads  and  writes  in  a  single  request  to  DIGIO. 

In  addition  to  detecting  whether  an  address  is  odd  or  even,  DIGIO  detects  three 
special  addresses  indicating  a  request  for  a  non-standard  operation  on  the  bus.  These 
are: — 

•  0000  —  DIGIO  treats  this  address  as  a  NOP  (no  operation)  and  does  not  process 
the  address  further.  The  need  for  such  an  address  arises  when  a  programmer 
wishes  to  reserve  a  "space”  in  digio_Bas8aga  for  a  future  bus  operation  that 
is  yet  to  be  developed. 

•  0001  —  DIGIO  sends  a  "trigger  all  analogue  to  digital  converters  (ADCs)”  to 
the  bus  to  begin  a  sample  of  the  current  data  values. 

•  FFFF  —  DIGIO  sends  a  "master  reset”  to  the  bus.  This  code  must  be  used  srith 
extreme  care  (see  further  comments  in  section  4.7). 

In  addition  to  sending  the  above  message  to  the  digio^boz  midlbox,  a  requesting 
process  must  also  notify  DIGIO  that  a  message  has  been  sent.  This  is  achieved  by 
setting  an  event  flag  (see  section  4.6)  —  number  65  for  a  low  priority  request,  or 
number  64  for  a  hi|^  priority  one. 
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4.4  The  DIGIO  Global  Common  Block 


To  coordinate  the  concurrent  use  of  DIGIO  by  several  processes,  and  to  provide  an 
efGcient  means  of  communicating  data  between  requesting  processes  and  the  parallel 
bus,  a  global  common  area  called  digio.conmon  is  created.  The  data  structures 
contained  in  this  common  area  are  maintained  either  by  DIGIO  itsdf  or  by  processes 
using  DIGIO.  The  common  block  and  the  variables  which  zire  contained  in  it  are 
defined  in  an  include  file  DIGIO.IKCLUDE.FOR  (Appendix  B).  The  data  structures, 
their  purpose,  and  their  usage  are  described  in  the  following  sub-sections. 


4.4.1  Bus  Module  Usage  Tables 

Wind  tunnel  data  gathering  devices  connected  to  the  parallel  bus  are  known  as  “in¬ 
strumentation  modules”  or  just  “modules”.  Eadi  module  is  electrically  distinct  and 
has  one  and  only  one  physical  connection  to  the  bus.  Modules  usually  coordinate  all 
data  transfers  associated  with  either  a  single  device  or  a  logical  grouping  of  tunnel 
instrumentation.  For  example,  there  is  a  strain  gauge  balance  module  incorporating 
six  strain-gauge  amplifiers,  thdr  analogue  to  digital  converters  and  their  associated 
controls,  which  coordinates  all  data  transfers  to  or  from  a  six-component  strain-gauge 
balance.  Other  modules  are  associated  with  Scanivalves,  tunnel  parameters,  etc.  In 
its  present  form,  the  parallel  data  bus  can  handle  up  to  16  modules  (numbered  in 
hexadecimal  from  80  to  8F),  but  this  could  be  extended  if  the  need  should  arise.  The 
current  allocation  of  modules  to  module  numbers  is  included  in  Table  1. 


Table  1:  Allocation  of  module  number  to  data  acquisition  modules. 


Module  Number 

Module  Name 

80 

Auxiliary  6-Channel  AC  Amplifiers  Module 

81 

Strain  Gauge  Module  with  6-Chaimel  AC  Amplifiers 

83 

Scanivalve  Module  with  6-Channel  DC  Amplifiers 

85 

VPT  Tunnel  Parameter  Module 

87 

LSWT  Tunnel  Parameter  Module 

8A 

Inclinometer  Module 

8B 

Actuator  Module 

Two  variables  in  digio.conmon  keep  track  of  those  modules  which  are  electrically 
connected  to  the  bus.  The  first  variable,  module.table,  is  a  logical  array  defined  as 

LOGICAL  mo<lul«_tabl«(0:15) 

in  which  each  element  is  set  to  .TRUE,  if  the  module  with  the  corresponding  number 
is  electrically  connected  to  the  bus.  The  second  variable,  nodul«_naflMs,  defined  as 

CHARACTER«80  modul«_nBB«s(0:18> 

is  a  similarly  dimensioned  array  of  character  variables  each  with  a  length  of  80 
characters.  If  an  element  of  nodula.tabla  is  .TRUE.,  the  corresponding  dement 
of  ]Bodala.naaas  will  contain  a  character  string  which  identifies  that  module. 
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whenever  DIGIO  receives  a  master  reset  command.  In  either  case,  DIGIO  attempts 
to  read  a  special  address  (8x60,  where  x  is  the  module  number  in  hexadecimal,  see  sec¬ 
tion  4.5)  contained  in  each  module  which  returns  that  module’s  identification  string. 
If  the  string  is  not  returned  after  10  milliseconds,  DIGIO  times  out  and  sets  the 
corresponding  entry  in  module.tabla  to  .FALSE.. 

Processes  requesting  data  transfers  via  DIGIO  may  use  the  information  in  this  data 
structure,  typically  to  ensure  that  all  modules  required  for  their  particular  data  trans¬ 
fers  are  present,  but  they  must  not  change  any  of  the  information  contained  in  these 
variables. 


4.4.2  Data  Arrays  And  Usage  Indicators 

When  writing  or  reading  data  to  or  &om  the  parallel  bus,  DIGIO  obtains  data  to  be 
written  and  stores  data  which  has  been  read  in  an  array  in  the  global  common  area 
defined  as 

INTEGER*2  data_list(1000) 

Each  process  transferring  data  via  DIGIO  is  allocated  one  or  more  blocks  of  50  ele¬ 
ments  within  this  array.  In  this  way,  the  data  belonging  to  one  process  using  DIGIO 
remains  independent  of  all  others.  To  keep  track  of  which  process  owns  which  block 
of  elements  within  data.list  and  to  determine  where  each  procecr’s  data  are  stored, 
DIGIO  maintmns  the  following  data  structure 

INTEGER*2  num.xaquastors 
LOGICAL  Tequestox.indax_table(5) 

LOGICAL  data_usage_tabl«(20) 


The  variable  nuD_r«qu«stor8  contains  the  number  of  processes  currently  using 
DIGIO  for  transfers  to,  or  from,  the  parallel  bus  —  the  number  of  processes  “con¬ 
nected”  to  DIGIO.  Currently,  the  maximum  number  of  processes  which  may  be  con¬ 
nected  to  DIGIO  at  any  one  time  is  set  (somewhat  arbitrarily)  to  5.  Whenever  a 
process  wishes  to  connect  to  DIGIO  it  must  first  check  that  nnn_r*quastors  is  less 
than  5,  and  if  so,  increment  num.r«que8tor8.  When  a  process  disconnects  from 
DIGIO,  num_r*qua8toT8  must  be  decremented. 

Having  incremented  nua_reque8tor8,  a  process  coimecting  to  DIGIO  must  then 
find  the  first  available  empty  (i.e.  .FALSE.)  element  in  requestor.index.table  and 
set  it  to  .TRUE..  The  index  of  this  element  then  becomes  that  process’s  unique 
i  dentifier  (requestor  index)  in  DIGIO  and  is  used  by  DIGIO  to  derive  several  quantities 
associated  with  that  process.  The  connecting  process  will  also  require  the  value  of  the 
requestor  index  and  it  should  therefore  also  store  it  locally.  When  discoimecting  from 
DIGIO  a  process  should  return  that  element  of  raquagtox.index.tabla  to  .FALSE. . 

A  connecting  process  must  then  allocate  one  or  more  blocks  of  50  elements  in  the 
array  data.list  for  its  own  use.  This  is  done  by  searching  the  data_usag«_tabl«  for 
an  empty  (i.e.  .FALSE.)  element  and  setting  that  element  to  .TRUE..  If  the  process 
requires  more  than  50  elements  of  data_list,  the  process  must  ensure  that  as  many 
subsequent  elements  of  data_usag«_table  as  the  number  of  blocks  (of  50  elements 
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in  data.list)  required  are  also  empty,  and  set  each  one  to  .TRUE..  In  other  words, 
the  elements  of  data_list  allocated  to  each  must  be  contiguotis. 

In  addition  to  the  above  variables  defined  in  the  DIGIO  global  common  block,  an 
integer  variable  data.asage_index,  defined  locally  within  the  connecting  process,  is 
used  to  store  the  first  entry  of  data_asage_table  that  is  allocated  to  the  process 
so  that  when  it  disconnects  from  DIGIO,  each  element  of  data_usage_table  set  by 
that  process  may  be  returned  to  .FALSE.. 

Another  requirement  of  a  process  connecting  to  DIGIO  is  to  determine  the  index  of 
the  address  in  data_li8t  where  data  for  this  process  begins.  This  index  is  stored 
in  an  integer  variable  data.start.addr,  also  defined  locally  within  the  connecting 
process,  and  may  be  calculated  via  a  statement  of  the  form: — 

data.start.addr  =  (data_usage_index  -  1)  *  SO  +  1 

4.4.3  Display  Process  Activity  Indicator 

The  display  process  activity  indicator  variable,  defined  by 
LOGICAL  dspon 

is  used  to  indicate  that  a  display  sub-process  (DSP???)  is  currently  active.  It  is  not 
part  of  the  DIGIO  data  structure,  and  is  only  included  in  the  global  common  area  for 
convenience  (this  common  is  available  to  off  processes  coimected  to  DIGIO).  It  is  used 
by  various  processes  to  determine  whether  or  not  certain  computations  which  are  only 
required  when  a  display  process  is  active  should  be  done.  (This  is  necessary  because 
display  processes  may  be  started  and  stopped  asynchronously  without  reference  to 
other  processes.) 

All  display  sub-processes  must  ensure  that  dspon  is  set  to  .TRUE,  when  they  are 
started,  and  returned  to  .FALSE,  when  they  are  stopped  (so  long  as  no  other  display 
sub-process  remrins  active). 

4.4.4  Linking  To  The  Global  Common  Block 

For  the  global  common  block  to  be  accessible  by  other  processes,  it  must  be  installed 
in  system  memory  as  a  shareable  image.  The  program,  DIGIO.ZNSTALLEU.FOR,  was 
created  to  install  digio.common  as  a  global  common  block.  It  contains  the  following 
three  statements: — 

PROGRAM  DIGIO.IMSTALLED 

mCLUUE  *  CDATAIM .DIGIO] DIGXO.INCLUDE . FOR/LIST  * 

ElTD 

The  program  is  compiled  and  linked  as  follow: — 

I  FORTRAN  DIGZO.ZNSTALLED 
$  LINX/SBAREABLE  DIGIO.INSTALLED 

The  file  protection  on  the  executable  code,  DIGIO.INSTALLED. EXE  needs  to  be  mod¬ 
ified  so  that  the  ‘‘world”  has  read  and  vrife  access  to  it.  This  is  achieved  by  the 
command: — 
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$  SET  PROTECTION :W=RW  DIGIO.INSTALLED.EIE 


To  install  the  image  (the  executable  code  of  a  program),  CMKRNL  privilege  is  required. 
The  following  steps  show  how  this  may  be  done: — 

I  SET  PROCESS/PRIVILEGEsCMKRNL 

t  INSTILL  CREATE  $DISK1: CDATAIN.EXE3DIGI0_INSTALLED.EXE  - 
/SHARED/WRITEABLE 
I  SET  PROCESS/PRIVILEGE=NOCHKRNL 

$DISK1:  CDATAIN.EXE]  is  the  directory  where  DIGIO_INSTALLEO.EXE  is  located. 

Any  process  that  wishes  to  transfer  data  to,  or  from,  the  parallel  bus  via  DIGIO 
should  include  the  global  common  block  in  its  source  code  via  the  statement 

INCLUDE  ' [DATAIN . DIGIO] DIGIO_INCLODB . FOR ' 

When  Hnlfing  the  object  code,  an  option  file  containing  the  line 

IDISKI : [DATAIN. EXE] DIGIO.INSTALLED/SEAREABLE 

must  be  included  in  the  LINK  conamand  with  the  /OPT  qualifier.  The  following 
dialogue  shows  how  DIGIO  .EXE  is  built  (DIGIO .  OPT  being  the  option  file): — 

i  FORTRAN  DIGIO. FOR 

$  LINK/EXE=OIGIO.EXE  DIGIO. OB J,DIGIOLIB.OLB/LIB. DIGIO. OPT/OPT 
DIGIOLIB .  QLB  is  the  object  library  containing  the  subroutines  used  by  DIGIO. 

4.5  Module  Addresses 

Each  module  number  on  the  parallel  bus  is  assigned  256  (lOOie)  addresses  of  the 
form  8z??i6,  where  z  is  the  module  number  in  hexadecimal.  Thus,  module  number 
5  is  assigned  addresses  from  8500 is  to  85FFi6.  However  only  those  addresses  above 
8z60i6  (i.e.  a  total  of  160  (AOie)  )  are  valid  external  read/write  addresses. 

To  avoid  the  need  for  system  software  developers  to  be  aware  of  the  hexadecimal 
addresses  of  each  function  on  each  module,  all  valid  parallel  bus  addresses  have  been 
mapped  to  an  array  defined  by 

INTEGER«2  address.liat (0:1599) 

Elements  of  addraas.list  are  defined  in  the  file  BUS. ADDRESSES. FOR  and  are  in¬ 
cluded  in  the  main  program  unit  of  DIGIO  at  compilation  time.  Referencing  this 
array,  rather  than  the  actual  bus  addresses,  allows  system  programs  to  be  written 
so  that  they  are  independent  of  changes  in  the  allocation  of  bus  addresses  within 
modules. 

The  three  special  bus  addresses  —  No  operation  (NOP),  master  reset,  and  trigger  — 
are  contained  in  addraas.listCO),  addzasa.listd)  and  siddr«s8.1ist(2)  respec¬ 
tively. 

Appendices  E  and  F  give  full  listings  of  the  allocation  c  f  bus  addresses  to  the  array 
addraaa.list.  Because  of  differences  in  module  construction  and  usage  in  the  two 
wind  tunnels,  bus  address  allocations  in  the  two  tunnds  are  different. 


4.6  Data  'transfer  Complete/Error  Notification 

When  DIGIO  has  completed  processing  a  data  transfer  request,  it  will  either: 

1.  set  an  event  flag  indicating  that  the  transfer  was  completed  successfully  (the 
success  event  flag)  or, 

2.  set  an  event  flag  indicating  that  the  transfer  failed  or  was  incomplete  (the  failure 
event  flag).  There  are  two  reasons  for  the  failure  event  flag  to  be  set: — 

•  the  data  bus  failed  to  respond  within  a  timed-out  period  (50  millisecond), 
or 

•  at  the  completion  of  a  low-priority  request  which  has  been  either  aborted, 
or  passed  over,  in  favour  of  a  high-priority  one. 

A  group  of  event  flags,  or  a  common  event  flag  cluster,  has  been  speciflcally  allocated 
to  be  shared  and  used  among  processes^  communicating  with  DIGIO.  This  event  flag 
cluster  is  created  with  the  STSllSCEFC  system  service.  A  process  can  reference  this 
cluster  by  invoking  the  same  STSlASCEFC  system  service  and  specif3ring  the  same 
cluster  name.  The  DIGIO  event  flag  cluster  is  given  the  name  of  dicluster  and 
is  assigned  to  a  character  array  variable,  digio_efn_cluster.  Note  that  although 
VAX  FORTRAN  is  a  case  insensitive  language,  the  event  flag  cluster  name  is  case 
sensitive.  Thus  to  create  or  associate  a  process  with  the  DIGIO  event  flag  cluster  the 
following  code  fragment  is  used. 

CHAIULCTER*9  digio.efn.clustar 

PARAMETER  (  digio.efn. cluster  «  ’dicluster'  ) 

status  s  STSIASCEFC  (  y.VAL(64),  digio.efn.cluster  >  ,  ) 

The  common  event  flag  cluster  thus  created  consists  of  the  32  event  flags  from  64  to 
95  inclusive. 

As  discussed  above,  most  errors  which  occur  on  the  parallel  bus  will  be  informative 
rather  than  fatal.  Typically,  these  errors  will  indicate  that  an  input  transducer  (such 
as  a  strain  gauge  amplifier)  has  been,  for  example,  over-ranged.  Generally  such 
events  will  not  occur  synchronously  with  requests  for  data  transfers.  Therefore,  the 
state  of  the  error  in^cating  interrupt  (REQ  A  bit)  on  the  DRVll  is  continuously 
monitored  via  an  Asynchronous  System  TSrap  (AST)  routine.  'Whenever  an  error  is 
detected,  control  is  transferred  to  the  AST  routine  (called  DIGI0_ERR0R_AST),  which 
determines  the  type  and  source  of  the  error.  It  interrogates  the  parallel  bus  and 
creates  an  error  message  contmning  the  module  number  in  which  the  error  occurred, 
an  indication  of  whether  or  not  the  error  is  fatal  (in  which  case  the  parallel  bus 
would  have  to  be  sent  a  master-reset  before  farther  data  transfers  are  attempted), 
and  a  description  of  the  error.  The  AST  routine  sends  this  message  to  a  mulboz 
—  the  error  m^boz  —  associated  with  each  process  currently  connected  to  DIGIO. 
The  error  message  is  packed  into  a  single  character  variable  40  characters  long,  the 
individual  components  being  avulable  via  an  internal  read  statement,  as  shown  in 
the  following  code  fragment: — 

'PtocesM*  can  abate  a  common  event  flag  clnster  only  if  they  have  the  tame  yronp  number  in 
tbcit  nset  identification  code  (UIC),  i.e.  they  ate  executed  by  uaeta  whose  UIC  hat  the  tame  gronp 
nnsnbet. 
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CHARACTER  error _inessage*40 ,  me6saga_text’«<37,  severity*! 

INTEGER*2  modnle.number 

READ  (error .message, 10)  severity,  module .number ,  message.text 
10  FORMAT  (  Al,  12,  A37  ) 

The  AST  routine  will  send  a  copy  of  the  error  message  to  mailboxes  with  names  ere* 
ated  by  the  concatenation  of  ’  error  .rnbox.'  with  the  requestor  index  of  each  process 
currently  connected  to  DIGIO.  Hence,  to  receive  an  error  message,  each  process  must 
create  a  mailbox  with  a  name  of  the  form  error.mbox.?,  where  ?  is  the  requestor 
index  of  the  process.  The  AST  routine  OIGZO.ERROR.AST  then  sets  an  error  event 
flag  associated  with  each  connected  process  to  indicate  that  an  error  message  has 
been  sent. 

To  allow  all  processes  connected  to  DIGIO  to  proceed  independently,  DIGIO  main¬ 
tains  a  separate  set  of  event  flags  —  efn.succass  (success  event  flag)  ,ef  n.lailuza 
{failure  event  flag)  and  efn.error  {error  event  flag)  —  for  each  connected  process. 
DIGIO  derives  the  event  flag  numbers  allocated  to  each  of  these  functions  from  each 
connected  process’s  requestor  index,  requestor. index,  via  code  of  the  form 

efn.success  -  63  3  *  requestor.index 

efn.failure  =  64  3  *  requestor.index 

efn.error  =  65  +  3  *  requestor.index 

which  allocates  3  consecutive  event  flag  numbers  for  each  connected  process  in  the 
range  of  66  to  80.  Each  process  connecting  to  DIGIO  should  therefore  compute  the 
event  flag  numbers  allocated  for  its  use  via  code  similar  to  that  above. 

It  should  be  noted  that  the  above  event  fij^s  numbers  (66  to  80),  together  with 
numbers  64  and  65  used  by  connected  processes  when  sending  request  messages, 
should  not  be  used  for  other  purposes. 


4.7  Master  Reset 

As  mentioned  above,  a  reference  to  address  .list  (0)  (which  translates  to  a  bus 
address  of  FFFFje)  in  a  data  transfer  request  causes  DIGIO  to  send  a  master  reset  to 
the  parallel  bus.  This  should  be  used  with  extreme  care  since  it  destroys  (initialises) 
all  data  stored  in  all  modules  connected  to  the  bus.  However,  a  master  reset  is  the 
only  way  to  initialize  the  parallel  bus  properly  at  power  up,  to  reset  the  bus  to  a 
known  state  whenever  a  module  is  electrically  connected  to  or  disconnected  from  the 
bus,  or  to  reinitialize  the  bus  following  a  fatal  (non-recoverable)  error. 

The  first  situation  is  taken  care  of  by  DIGIO.  The  other  two  are  the  responsibility 
of  system  processes.  However,  before  sending  a  master  reset  request  to  DIGIO  and 
hence  to  the  bus,  a  process  must  be  the  only  process  connected  to  DIGIO  —  any  other 
process  would  have  no  knowledge  of  the  change  to  the  data  on  the  bus.  A  process 
which  wishes  to  initiate  a  master  reset  must  therefore  ensure  that  aum.zequeitors 
is  equal  to  one,  indicating  that  only  one  process  (itself)  is  connected  to  DIGIO. 
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5  SUMMARY  OF  REQUIREMENTS  FOR  A  PROCESS  COMMU¬ 
NICATING  WITH  THE  BUS  VIA  DIGIO 


The  following  sections  sununarize  the  actions  which  must  be  taken  by  a  process  that 
needs  to  transfer  data  to  or  &om  the  parallel  bus  via  DIGIO.  Many  of  these  have  been 
at  least  implied  in  the  descriptions  of  how  the  various  parts  of  the  system  operate  in 
previous  sections.  However,  in  the  following  sections,  the  actions  are  grouped  in  a 
logical  order,  and  code  fragments  to  achieve  each  action  are  provided. 


5.1  Definition  Of  Variables 

Before  communicating  with  DIGIO,  the  data  structure  must  be  set  up  correctly  for 
the  process.  The  following  are  deiinitions  of  some  of  the  more  important  variables. 

1.  All  system  routines  must  be  defined  as  INTEGER*4  variables  before  being  used. 
Some  of  these  routines  are 

INTEGER«4  status . 

1  STSICREMBX. 

2  SYSliSSIGN. 

3  STS$ASCEFC. 

4  SYS$DACEFC, 

6  SYSISETEF, 

6  SYSICLREF, 

7  SYSIWFLOR, 

8  SYSlqiOW 

The  variable  status  is  widely  used  to  hold  the  return  status  code  of  the  system 
routines,  and  must  be  defined  as  an  INTEGER*4  also. 

2.  Two  condition  codes  defined  in  the  system  object  and  shareable  image  libraries 
used  in  the  process’s  code  must  be  made  known  to  the  process.  The  easiest  way 
to  do  this  is  to  define  the  condition  codes  as  external  symbols,  thus 

EXTERNAL  ssl.vasset 
EXTERNAL  ssl.endolfile 

The  codes  may  then  be  referred  to  by  using  the  built-in  function  %L0C  which 
returns  the  address  of  its  argument. 

3.  Several  variables  must  be  available  to  all  program  units  (routines)  in  the  process. 
These  would  normally  be  included  in  a  common  block  shsured  by  all  program 
units.  These  variables  are: — 

CBARACTER  digio_B*ssag**256 
INTEGER*2  digio.abox.chaa, 

1  error _abox_ chan 


INTEGER*4  requestor.index , 
1  data.start.addr , 


2  efn.success, 

3  efn.failuTd. 

4  efn_«rror, 

5  efn.mask 

4.  The  remaining  group  of  variables  need  only  be  defined  in  the  program  unit  in 
which  they  are  used.  These  should  be  defined  as  follows: — 


CHARACTER 

6rTor_mboz_namavl2 . 
OTzoz .me ss age v40 

CHARACTER 

digio.mboz.name’*  (  v  ) 

PARAMETER 

(  digio.m.70X_name  = 

’ digio.mboz '  ) 

CHARACTER 

digio_eln_cluster*(*) 

PARAMETER 

(  digio.efn. cluster 

=  'dicluster'  ) 

rNTEGER>»4 

mboz.vrite.code 

PARAMETER 

(  mboz.vrite.code  = 

'70'X  ) 

INTEGER*4 

mboz.zead.code 

PARAMETER 

(  mboz.read.code  =  ’ 

71'I  ) 

Note  the  use  of  PlRiMETER  statements  to  define  several  constants.  The  dis¬ 
advantage  of  not  being  able  to  include  such  variabl  s  in  COMMON  blocks  is  out¬ 
weighed  by  the  protection  given  to  their  values  —  any  attempt  to  change  the 
value  of  a  constant  defined  via  a  PARAMETER  statement  will  produce  an  error  at 
compilation  time. 

There  are  two  include  files  designed  to  facilitate  the  creation  of  the  above  data  struc¬ 
ture.  They  are  OIGIO.INCLODE.FOR  and  DIGIO.DEFS.FOR,  both  of  which  reside  in 
the  directory  IDISXl:  [OATAIN .  DIGIO] . 

DIGIO. INCLUDE. FOR  defines  the  global  common  block,  DIGIO.COMMON,  and  its  asso¬ 
ciated  variables  (section  4.4).  It  must  be  included  in  each  program  unit  (subroutines 
and  functions)  which  references  any  one  of  these  variables.  A  listing  of  this  include 
file  is  given  in  Appendix  B.  Note  that  when  linking,  an  option  file  must  be  included 
to  link  to  this  shared,  shareable  conomon  (see  section  4.4.4). 

DIGIO.DEFS.FOR  defines  the  standard  variables  (groups  of  variables  referred  to  in 
items  3  and  4  above)  re^iaired  by  a  process  when  communicating  with  DIGIO.  It 
defines  the  variables  common  (but  defined  locally  within  the  process)  to  all  requesting 
processes  such  as  digio.mboz.nama,  lov.priority.aln  and  high.priority.afn.  It 
also  defines  process-specific  variables  such  as  digio.nboz_chan,  •rror.mbox.naaa, 
raquaator.indaz  and  so  on.  These  process-specific  variables  are  grouped  into  a 
commoa  block  named  procass.coamon  so  that  they  may  be  used  by  all  the  routines 
within  the  process.  Appendix  C  contuns  a  listing  of  this  file. 

These  files  are  included  into  the  appropriate  program  units  with  the  statements 

INCLUDE  'IDISKI: CDATAIN.DIGZ0]DIGI0_INCLUDE.F0R* 

INCLUDE  *$DISK1: [DATAIN.DIGI0]DI6I0_DEFS.P0R' 

and  the  appropriate  variables  will  be  defined  and  set  up  accordingly. 
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5.2  Connecting  To  DIGIO 


Before  a  process  can  transfer  data  to  or  from  the  parallel  bus,  it  must  “connect”  to 
DIGIO  via  the  following  steps: — 

1.  Associate  the  DIGIO  common  event  flag  cluster  with 

status  =  SYStASCEFC  (  %VAL(64) ,  'diclustar'  ) 

2.  Connect  to  the  DIGIO  mailbox  by 

status  =  STSIASSIGN  (  digio.mbox.name ,  digio.mbox.chan.  .  ,  ) 

3.  Increment  the  number  of  processes  connected  to  DIGIO  via 

num.requestors  =  num.raquestors  1 

Note  that  the  value  of  uum.raquestors  should  be  checked  before  incrementing 
and  if  it  is  greater  than,  or  equal  to  5,  the  connection  cannot  be  made  until  one 
or  more  processes  disconnects  from  DIGIO. 

4.  Determine  the  process’s  requestor  index  via 

i  »  1 

00  WHILE  (  T«questor_index_table  (  i  )  ) 
i  *  i  +  1 
END  DO 

requastox.indax.table  (  i  )  =  .TRUE, 
raquastox.indsx  =  i 

The  above  code  locates  the  first  empty  (.FALSE.)  element  in  the  array 
r«qu«stor_indax_table,  sets  it  to  .TRUE,  and  remembers  the  value  as 
raquastor. index. 

5.  Create  the  process-specific  error  maolbox  via 

•rror_obox_uaa«(i:ll)  =  ’ error _mbox_’ 

WRITE  (error_aboz_naoe(12:12),10)  requestor.index 
..0  FORMAT  (  II  } 

status  «  STS$CRENBZ  (  XTAL(l), 

1  error.mbox.chan, 

2  y.VAL(40).  ,  ,  , 

3  error.mbox.naoe  } 

6.  Determine  a  starting  address  i'<.r  rhe  process’s  data  storage  area  in  data.list. 
First  locate  the  first  empty  (  F  . )  element  in  the  array  data.usage .table 
via 


i  ■  1 

DO  WHILE  (  data.nsage_table(i)  .AND.  i  .LE.  20  ) 
i  ■  i  ♦  1 
END  DO 
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If  this  process  requires  50  or  less  locations  in  data_list  (which  will  be  the  case 
for  most  of  the  processes  connecting  to  DIGIO),  the  area  in  data.list  pointed 
to  by  this  element  of  data.U6agd_tabl«  will  be  sufficient.  The  connecting 
process  must  now  mark  this  element  in  data_usage.tabl«  as  being  used  and 
add  the  computed  starting  address  to  data_start.addr.  The  index  of  the  first 
entry  in  data_usage.tabl«  is  stored  in  data_usage_index  via 

data_usage_table(i)  »  .TRUE. 
data_n8ag«_ index  ^  i 
data.start.addr  =(i-l)*50+l 

If  this  process  requires  more  than  50  locations  in  data_list,  then  it  must  en¬ 
sure  that  as  many  subsequent  elements  of  data_usage.table  as  the  number  of 
blocks  (of  50  elements  in  data.list)  required  are  also  free  (.FALSE.).  Other¬ 
wise,  the  procedure  is  as  set  out  above. 

In  both  cases,  if  less  than  the  required  number  of  elements  in  data.usage.table 
is  available,  the  connection  must  be  aborted. 

7.  The  event  flag  numbers  allocated  to  this  process  must  be  computed  from  the 
value  of  requestor,  index  via 

ejCn.success  =  63  requestor.index  *  3 
efn.failure  s  64  requestor.index  *  3 

efn.error  s  65  requestor.index  *  3 

To  allow  the  process  to  detect  the  setting  of  either  the  success  or  failure  event 
flag  via  the  STS$WFL0R  system  service  routine,  an  event  flag  mask  can  be  created 
which  is  the  logical  OR  of  the  success  and  failure  event  flag  numbers.  This  may 
be  achieved  as  follows 

«fn.Ba8k  =  0 

«fn.mask  •  IBSET  (  •fn.oask,  MOD  (  •fn.success,  32  )  ) 

•fn.ma8k  *  IBSET  (  •fn.mask,  MOD  (  ofn.lailuro,  32  )  ) 

The  above  procedures  have  been  included  in  the  subroutine  CONNECT.DICIO  with  the 
standard  variables  defined  as  in  DIGIO.DEFS.FOR.  The  calling  syntax  of  this  routine 
is 


CALL  CONNECT.DIGXO  (  digio.status  ) 

where  digio.status  is  an  IHTEGER*4  variable  (pre-defined  in  DIGIO.DEFS.FOR)  re¬ 
turned  from  CONHECT.DIGIO  indicating  if  the  connection  is  successful  (1)  or  not  (0). 

This  subroutine  is  contained  in  the  object  library  DIGIOLIB.OLB  located  in  the  direc¬ 
tory  IDISKI:  [OATAIR. DIGIO],  and  may  be  linked  to  the  executable  code  of  a  user 
program  with  the  LINK  qualifier  IDISKI:  [DATAIR. DIGIO] DIGIOLIB.OLB/LIB. 

5.3  IVansferring  Data  Via  DIGIO 

Once  a  process  has  snccessfully  connected  to  DIGIO  it  may  read  or  write  data  from 
or  to  the  parallel  bus  by  sending  request  messages  to  the  digio  mailbox. 
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Whether  the  request  is  for  a  read  or  a  write,  the  first  part  of  the  DIGIO  message 
remains  the  same,  varying  only  with  the  priority  of  the  request.  It  is  therefore  useful 
to  generate  this  "header”  part  of  the  message  once,  and  then  to  use  it  as  part  of  all 
subsequent  messages.  This  may  be  done  via 

digio_messag«(l:l)  s  *1* 

WRITE  (digio_message(2:3),10)  reqnestox.index 
10  FORMAT  (  II.  II  ) 

which  generates  a  high  priority  request  message.  Substitution  of  an  ’L’  for  the  'H' 
achieves  the  same  for  a  low  priority  request. 

The  remainder  of  the  message  is  dependent  on  the  particular  data  to  be  transferred. 
If,  for  example,  six  variables  (e.g.  the  outputs  of  six  analogue  to  digital  converters) 
are  to  be  transferred  from  the  sting  balance  strain  gauge  module,  the  remainder  of 
the  message  could  be  generated  via 

digio.m«ssage(4:36)  «  *  6  102  103  104  lOS  106  107' 

which  indicate  that  six  addresses  are  to  be  transferred  and  includes  the  indices 
of  the  required  elements  of  addzoss.list.  These  values  are  defined  in  the  file 
BUS  .ADDRESSES.  FOR  which  is  used  by  DIGIO  as  a  look  up  table  for  the  appropri¬ 
ate  addresses  to  be  sent  to  the  data  bus. 

The  request  message  is  sent  to  the  DIGIO  mailbox  via  the  system  service  routine 
SYStqiOW;— 

status  ~  STSAQIOW  <  ,  %TAl(digio_abox_chan) , 

1  XVALlmbox.uxita.code) ,  ,  ,  , 

2  XREF(digio_m«s8age) . 

3  XVAL(256),  ,  ,  ,  ) 

The  requesting  process  should  then  wait  for  DIGIO  to  set  either  the  success  or  failure 
event  flag  to  indicate  that  the  request  has  been  completed,  determine  which  event 
flag  was  set,  and  process  the  data  as  required. 

The  subroutine  DIGIO.SEND  is  designed  to  simplify  the  process  of  constructing  the 
digio_m«ssag«  and  the  SYSlQIOW  calling  sequence.  To  request  a  data  transfer,  it 
is  only  necessary  to  put  the  required  address  indices  into  the  array  addr.indax  and 
invoke  the  routine  with  the  following  sjmtax: 

CALL  DIGIO.SEND  (  nua.addzasses ,  addr.indax,  digio.status  ) 


where 

•  Bna_addr«ssas  —  is  an  1HTEGER*4  variable  (pre-defined  in  DIGIO.DEPS.FOR) 
indicating  the  munber  of  addresses  to  be  sent, 

•  addx.index  —  is  an  ZITEGER«2  array  (pre-defined  in  DIGIO. DEFS. FOR)  con¬ 
taining  the  indices  of  the  addresses  to  be  sent,  and 

•  digio.status  —  is  an  IRTEGER*4  variable  indicating  the  return  status  of  the 
routine.  If  digio_status«l  the  operation  is  successful.  If  digio_status«0  the 
operation  fsuls,  and  if  digio.status*-!  an  error  has  occurred. 
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The  object  code  of  DIGIO.SEND  is  found  in  lOISKl :  Cl>iTlIN.DI6I0]DI6I0LIB.0LB 
and  may  be  linked  to  a  user’s  program  in  the  usual  manner. 

Note  that  the  values  read  from  the  parallel  bus  are  stored  by  DIGIO  in  data_list, 
beginning  at  the  start  of  the  requesting  process’s  area,  i.e.  at  data_start.addr,  and 
in  the  same  order  as  they  appear  in  the  request  message  or  in  addr.indez.  The  values 
are  returned  in  data_list  as  INTE6EB*2  variables,  and  are  able  to  represent  the  full 
16  bit  precision  generated  by  the  analogue  to  digital  converters  used  on  the  parallel 
bus.  Outputs  from  the  analogue  to  digital  converters  are  returned  by  DIGIO  as 
offset  binary  (0000i6=+32768io,  7FFFi6=0io,  and  FFFFig=— 32767io)*  To  convert 
the  values  in  data.list  from  this  form  to  the  two’s  complement  binary  used  by 
the  Micro  VAX  (8000i6=~32768io»  0000i6=0io  and  7FFFi6=+32767io),  the  following 
code  fragment  may  be  used. 

INTE6ERV2  mask 
PARAMETER  (  mask  =  ‘TFFP’X  ) 

adc.valueCi)  =  IIEOR  (  data_list(j) ,  mask  ) 

Note  that  there  are  two  “reserved”  words  in  the  range  returned  by  DIGIO;  OOOOig  or 
null,  and  FFFFie  which  if  returned  indicates  that  the  data  are  not  valid. 

To  write  data  to  the  bus,  the  procedure  is  similar,  with  the  obvious  exception  that  the 
data  to  be  written  must  reside  in  data_list  before  the  request  message  is  sent.  For 
example,  to  send  a  value  to  the  bus  to  be  used  as  a  reference  length  for  the  Re3molds 
ntimber  calculations  (for  which  the  bus  address  resides  in  addx»ss_list(522)),  the 
following  code  could  be  used. 

data.list(data.start_addr}  =  renlen  /  1000. 
digio_message(8:15)  =  *  1  522’ 

status  =  STSIQIOW  (  ,  %TAL(digio.mbox.chan) , 

1  %TAL(mboz.vrTite.code) ,  ,  .  , 

2  XREF(digio_m«8sag«) , 

3  XVAL(256),  ,  ,  ,  ) 

status  >  STSISETEF  (  XVAL(64)  ) 

status  »  STSIWFLOR  (  XVAL(64),  XVALCefn.mask)  ) 

status  s  STSICLREF  (  XVAL(«fn.failur«)  ) 

IF  (  status  .EQ.  XL0C(ss$_vasset}  )  THEM 

C  Failure  flag  was  set  -  do  whatever  is  necessary 

EMD  IF 

If  the  subroutine  OIGIO.SEMD  is  employed,  the  code  fragment  would  then  read: — 

data_list(data.8tart_addr)  ■  renlen  /  1000. 
nnm_addresses  ■  1 
addr.index(l)  «  622 


25 


c 


CALL  DIGIO_SEND(  num.addresses ,  addr.index,  digio.statns  ) 
IF  (  digio.status  ) 

Operation  successful! 

ELSE 

C  Operation  failed! 

END  IF 


5.4  Treating  Errors 

Whenever  an  error  occurs  on  the  parallel  data  bus,  DIGIO  sends  an  error  message  to 
the  specific  mailbox  associated  with  each  process  connected  to  DIGIO  (this  m^box 
was  created  in  step  6  of  the  connection  process,  described  in  section  5.2,  or  in  the 
DIGIO.CONNECT  routine).  Whenever  DIGIO  sends  such  a  message  it  notifies  each 
connected  process  by  setting  its  error  event  flag.  Bus  errors  may  occur  at  any  time, 
and  if  not  read  by  a  connected  task,  will  simply  accumulate  in  each  process’s  error 
mailbox.  Thus  whenever  it  is  important  for  the  process  to  be  aware  of  possible  errors, 
the  error  event  flag  should  be  checked  and,  if  set,  control  transferred  to  a  routine  which 
reads  and  decodes  the  error  message.  This  may  be  achieved  via  code  such  as 

status  s  STSICLREF  (  X7AL(«fn_error)  ) 

IF  (  status  .EQ.  XLOCCsst.vassat)  }  THEN 
CALL  TREAT.ERROR 
END  IF 

It  is  important  that  coimected  processes  check  the  error  event  flag  after  each  data 
transfer  (to  ensure  the  validity  of  data  sent  or  received),  and  also  before  sending 
a  request  message.  If  a  fatal  error  has  occurred  since  the  error  event  flag  was  last 
checked,  any  further  messages  sent  to  DIGIO  will  not  be  treated  correctly,  and  at 
worst,  DIGIO  may  never  reply  to  the  message,  thus  hanging  the  requesting  process. 

The  routine  used  to  read  and  decode  error  messages  must  allow  for  the  possibility  that 
more  than  one  error  message  has  accumulated  in  the  error  mailbox.  One  approach 
to  this  would  be  as  follows: — 

STRUCTURE  /iostat .block/ 

INTEGER*2  status,  osg.lsngtb 
INTEGERV4  ssndor.pid 
END  STRUCTURE 

RECORD  /iostat .block/  mbox.iosb 
CHARACTER  •rroT_m«ssag«*40 
EXTERNAL  ssl.ondoff ilo 

Bbox.iosb. status  »  1 

DO  WHILE  (  Bbox.iosb. status  .IE.  XLOC(sst_andoffilo)  ) 

C  *****  Road  ths  Mailbox  until  no  aoro  Bossagos 

status  ■  STStQIOW  (  .  XVAL(*rrox.Bbox.chan) , 

1  XTAL(Bbox_r*ad_cod*), 

2  Bbox.iosb,  ,  , 

3  XREF(«xror.B*ssag*), 
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•/.VAL(40),  .  ,  ,  ) 

IF  (  mbox.iosl). status  .EQ.  XLOCCssI.endoffile)  )  RETURN 
C  *****  Decode  the  error  message  and  treat  accordingly 


END  DO 

The  external  variable  ssi.endollile  is  the  system  service  status  code  indicating 
that  there  are  no  more  messages  in  the  mailbox. 

S.S  Disconnecting  From  DIGIO 

Before  a  process  which  has  connected  to  DIGIO  exits,  it  must  return  the  DIGIO  data 
structures  to  their  original  state.  This  may  be  done  using  the  following  steps. 

1.  Return  this  process’s  entry  in  requestor.indax.table  to  .FALSE,  i.e. 

requestor.index.table  (requestor.index)  =  .FALSE. 

2.  Return  this  process’s  entry  in  data_usage.tabl«  to  .  FALSE .  i.e. 

data_usag«_tabl«  (data_nsage.indax)  =  .FALSE. 

3.  Decrement  num_requ«stor8. 

4.  Disassociate  the  DIGIO  common  event  flag  cluster  via 

status  s  STSIDACEFC  (  %VAL(  64  )  ) 

5.  Delete  the  error  mailbox  associated  with  this  process: 

status  s  STSlOELMBX  (  XVALC  «rror_mbox_chan  )  ) 

The  process  is  then  free  to  exit.  The  subroutine  EXIT.DI6I0  is  provided  to  perform 
the  above  tasks  and  is  called  by 

CALL  EXIT.DIGIO 

EXIT_DIGIO  is  contained  in  the  object  library  $DISK1 :  [DATAIN .  DIGIO]  DIGXOLIB .  OLB. 


6  CONCLUSIONS 

A  software  interface,  DIGIO,  has  been  developed  for  the  new  data  acquisition  system 
in  the  two  main  wind  tunnels  at  ARL.  It  has  been  developed  on  a  DEC  MicroVAX  n 
computer  equipped  with  a  DRVll  parallel  I/O  interface  adapter.  Access  to  the  three 
registers  of  the  DRVll  adapter  is  provided  from  the  software  by  direct  mapping  of  the 
Q22-Bus  I/O  page  to  program  variables.  This  method  produces  a  fMt  and  efficient 
means  of  communicating  with  the  parallel  data  bus  via  the  DRVll  interface. 
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DIGIO  handles  all  the  instrumentation  control  and  data  transfer  requests  from  various 
data  acquisition  processes.  Up  to  hve  processes  may  access  the  parallel  data  bus  at 
one  time,  which  provides  great  flexibility  for  developing  data  acquisition  software. 
Details  have  been  provided  of  the  steps  which  must  be  included  when  developing 
data  acquisition  software  that  needs  to  access  the  data  bus  via  DIGIO. 
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APPENDIX  A 


MODIFICATIONS  TO  THE  DRVll  CIRCUIT  BOARD 

A  design  fault  in  the  circuitry  of  the  DRVll  circuit  board  prevents  the  interlace  card 
from  hinctioning  properly.  This  has  been  corrected  by  naodiiying  the  circuitry  of  the 
Integrated  Circuit  chip  at  the  right  hand  top  comer  on  the  component  side  of  the 
board,  as  shown  in  Figure  A.l.  The  modifications,  as  shown  in  detail  in  Figure  A.2 
are:- 


•  The  electrical  connection  between  pins  8  and  9  is  broken  by  cutting  the  circuit 
path  between  the  two  pins  on  the  circuit  side  of  the  board. 

•  A  jumper  is  wired  between  pins  6  and  9  to  provide  electrical  connection  between 
the  two  pins. 


Figure  A.l:  Schematic  layout  of  the  DRVll  adapter  board. 


Bectricai  connection 
cut  between  pins 
8and9 


Figure  A.2:  Enlarged  view  of  the  chip  to  which  modifications  are  made. 
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APPENDIX  B 


LISTING  OF  THE  INCLUDE  FILE  DIGIOJHCLUDE.FOR 

c**************************  s-rm  OF  DI€I0_I»CU5DE.F01  •••••••••••••••••••••••••• 

c - 

C - 

C  D«fin«  Modnl*  Uatgm  Data 

C - 

LOOICAI.  modiila_Tabla(0:15) 

CI1&&CTEK*80  a<idiaa_Iama(0:lS) 

C - 

C  Dafina  DIGIQ  Oaaga  Indicators 

C - 

ItlTS6BK*2  nfim_Baqnastors  !  Tha  rnuabar  of  procassas 

•  conaactad  to  DI6I0.  (aax  5) 

LOGICiL  raqeostor_ittdaz_tabla(5)!  Trna  if  procass  coanactad 

!  aith  this  iadar. 

LOGICIL  data_nsaga_tabla(20) ,  !  Trua  if  tha  50  location 

!  block  of  data.list  is  ia  asa. 

1  dspon  !  Trna  if  a  display  snb.procass 

!  is  azacntiag. 

C - 

C  Dafina  raxiabla  to  data  arrays 

IITBGEK*2  data.ListdOOO)  !  Array  to  hold  bas  data 

C - 

C  Dafina  Global  Coonon  Block  DIGIO.COMMOl 

COMHOI  /digio.coonoa/  nodala.T^la,  awdala.Baaa , 


1  nna.Eaqnoators,  roq^aostor.indaz.tabla , 

2  ro^astor_start_add,  data.asaga .table, 

3  data.List, 

5  dspon 


C  aaaaoaaoaaaaaaaaaaaaaaa  EID  OF  DIGIQ_XICUn>B.FOE 


!  Traa  if  modnla  aloctrieally 
•  coanactad  to  tha  has. 

!  Ratamad  ahaa  siodnla 
!  intarrogatad. 


APPENDIX  C 


LISTING  OF  THE  INCLUDE  FILE  DIGI0J)EFS.F0R 

C****************************  STIRT  OF  DieiO.IffiFS.FOR  ••••••••••••••••••••••< 

C - 

c - 

C  Coanonly  uad  variablM  for  eoamaication  vith  OIGIO 

C - 

CHIRACTBR  azTor_Biboz_BaBo*12, 

1  •rror_Mas«ga«40 , 

2  priority*! 

ZITB6BR*2  digio_iBboz_eliaa.  !  digio  nail  boz  chaanal 

1  *rroz_gA>oz_cl>aa,  !  ozror  mail  boz  ebannol 

2  addz_iiid*z(SO)  !  indaz  of  BPI  bna  addroBa** 

IBT£GE&*4  zaqaaator .indaz, 

1  digio.atatna, 

2  data.atart.addr, 

3  higb_priority_afm, 

4  lo«_priority_afn, 

B  af a.auecaaa , 

6  af n_f  ailnxa , 

7  af n.arror , 

8  afa.timar, 

9  afa.maak 

PASAHBTER  (  loa.pziority.afa  *  6S  ,  !  afa  aat  by  raqaaatiag  proeaaa 
1  bigh.priority.afa  •  64  )  !  dapaadiag  oa  priority 

PiUMETER  (  afa.timar  »  9S  )  !  afa  of  tho  timor  to  bo  aat  if 

!  DIGIO  doaa  aot  raapoad  aitbia 
!  tho  tiaooat  pariod 

CHARiCTSR  digio_adioz_Bama*(*) 

PARiKETER  (digiojBiboz_aaaa  -  ’digio.aboz’) 

CH1RIC7ER  digio_ofa_clnat*ra(*) 

PiRlKBTBR  (digio_afa_claBt*r  >  'diclastor’) 

C  Tha  folloaiag  coamoa  block  ia  aharad  by  reatiaaa  withia  tha 


C  aama  proeaaa  oaly. 

C - 

CDmOl  /procaaa.eomBna/  digiojaboz.chaa,  orror.Bboz_Baaw, 

1  azTorjabex.chaa,  xa^oator.iadoz, 

2  data.atazt.addr ,  af a.aaccaaa , 

3  afa.failara,  afa.ozror,  *fB_maak, 

4  ^iority 

C  aaoaaaaaaaa***************  gn  OF  DIGIO.DSFS.FOR  aoaao********* 


u  u 


APPENDIX  D 


LISTING  OF  THE  SUBROUTINE  DRJEHIT.FOR 

SOBROiniHE  dz.init 

C  This  Sabzoutiaa  initializaa  tha  DRTll  “dzxTax".  It  doaa  tha 

C  lolloaiag:- 

C 

C  (1)  Mapa  tKa  paga  at  phyaical  Baawry  contaiaiiig  tha  DSll’a 

C  ragiatara  (part  of  tba  Q22  baa  oz  lO-paga)  to  tba  pzocaaaaa 

C  Tixtnal  aaaozy.  Rafazaaeaa  to  thaaa  locatioaa  on  tba  Q22  boa 

C  aay  than  ba  aada  by  zalozaaca  to  tba  azzay  ''dz.iopago"  wbicb 

C  ia  256  aozda  (512  bytaa  -  1  paga)  loag,  coataiaad  is  coaaoa 

C  block  ''dz.caoBOB"  abicb  ia  liakad  to  ba  paga  aligaad  ria  tba 

C  link  option  fila  “dz.iait.t^t" 

C 

C  (2)  Coimacta  to  tba  ORll’a  iatazziipt  ooctoza.  Than  wbanoTaz 

C  intazzapt  i  ia  aat,  azant  flag  10  aill  ba  zaiaad,  aad  BbanoTar 

C  iatazziq>t  B  ia  aat,  tba  AST  zontina  digio_aKzoz_aat  aill  bo 

C  ozacatad,  Tbia  AST  zoutiaa  tzaata  and  aignala  all  bna  azzoza. 

C 

c - 

c - 

C  iBelada  coanona 

C - 


nCLUDB  ’  [dataiii.digioldz_iacluda.foz/liat’ 


C - 

C  Dafiaa  ayataa  roatiaaa  naad 

C - 


BXTBBIAL  ioS.coniatzaad 

nCLUDE  '  (taacdaf )  ’ 


UTEGUoA 

2 

7 

8 
6 


atataa, 

ayalaaaiga, 

ayalqio, 
ayaScmpac , 
liblaigaal 


ayataa  aazzica  zoatiaoa. 
aaaiga  a  cbaaaal  to  aboz 
ijuaua  aa  i/o  zaqaoat. 
czaata  a  aappad  aactioa. 
aigaal  azzoz. 


C - 

C  Dafiaa  zaziabloa  foz  CBKPSC  Call 


IBTBGBBaA  dz_iBadz(2) ,  !  Tao  loagwozds  to  coataia  io  paga  addzaaa 

1  dz_ratadz(2)  !  Tao  loagaozda  to  coataia  zatazaod  addzaaa 

ZITB6BKa4  pfa  !  io-paga  fzaua  aaiAaz 

PABAMBTBB  (  pfa  -  ’100007’X  ) 

IITB6SBa4  Mok  !  Loagaezd  to  coataia  aactioa  ebaractaziatica 

!  -  pfa  uappiag.  azitaabla 

PABAHBTU  (  aaak  ■  aac|u_pfaMp  .Qt.  aac8B_azt  ) 


Dafiaa  aaziablaa  foz  ASSiei  Call 
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A  A 


c - 

IITBGBE*2  dxa.elmi  !  Cltaiiji*!  anabar  fox  iatampt  i  "daTica*' 

1  dxb.diaa  !  Cbaaaal  anabar  for  iatarrapt  B  “daTica” 

C - 

C  Sat  np  yariablaa  fox  Conaact  to  latoxxapt  Call 

C - 

UTKGBBal  fcoda  !  Faactioa  coda  aoxd 

STBUCTOKB  /flag/ 

DIIOI 

fUP 

HTBGUoS  aaitcbaa  /S/  !  ciata_xapaat  or  ciaSa.afa 

UTBGB&al  ofaaa 
BBS  NAP 
MAP 

HTBGERoA  flagaord 
BBD  MAP 
BID  nilOfl 
BBD  STRUCTDBE 

BBCOBD  /flag/  dia.flaga 
BECOBD  /flag/  dxb.flaga 

BXTBBBAI.  digio_axxox_aat 

C - 

c  aaaaaaaaaaaaaaaoBBGIBnBG  OF  BXBCDTABLE  CODBaaaaaaaaaaaaaaaaa 

C - 

C - 

C  Sat  ap  yariablaa  aad  aap  io-paga 

C - 

dr.iaadxd)  >  XL0C(  dr.iopaga(0}  } 
dr_iaadr(2)  -  XLOC(  dx.iopaga(25S)  )  +  1 

atatas  *  STStCRKPSCC  dr.iaadr,  dr.ratadr,  ,  XFAK  aaak  . 

1  ,  1,  XTAL(  pfa  ).  ,  ) 


Cback  that  tba  aappiag  aaa  doaa  corractlp  -  iapat  aad  rataxa 
ataxt  aad  aad  addraaaaa  aboold  ba  tba  aaaa 


IF(  .lOT.  atataa  )  CAU  LIBtSZGBAK  XTAI(  atataa)  ) 

IF(  (  dr.iaadxd)  .BE.  dr.ratadxd)  )  .OK. 

1  (  dr.iBadr(2)  .BE.  dr_xatadx(2)  )  )  THEB 

TTPE  a,  ’  aaa*  lO-Paga  aot  aappad  coxxactly' 

TYPE  10.  dr.iaadrd),  dr_iaadr(2) 

10  FOIKAT  (  *  Iapat  addraaaaa  axa  Z6,  5Z,  Z6) 

TTPE  20.  dr.ratadxd).  dx.xatadx(2) 

20  PODUT  (  ’  Bataraad  addraaaaa  axa  *.  Z6.  51,  Z6) 

CAU  LIBtSZGBU(  ZTAK  atataa)  ) 

BBD  17 

Aaalga  both  "dayleaa”  aad  gat  cbaaaal  aaabara 
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statu*  »  STSiiSSIGSC  dxa.chan,  ,  ) 

1F(  .lOT.  statas  )  CllL  LIB«SZ6KU.(  Xm(  status)  ) 
status  -  STStlSSIGX  drb.clisn,  .  ) 

IF(  .MOT.  status  )  CALL  LIBASIGMAL(  XTAL(  status)  ) 


C - 

C  Couuact  to  iatazxupts  on  both  chsiiaols 

C - 

c - 

C  Fox  OAIO:  -  RBQ  A  -  tho  doaa  flag  -  raisa  afn  1 

C - 


foods  >  XLOC (lot .Coniat Asad) 
dxa.flags.afnnt  »  1 

status  -  STSMQIO  (  .  XTAL  (dxa.cbaa  ) ,  XrAL(  foods  ) 
1  XTAL  (  dra.f lags .f lagsord  ) .  >  >  ) 

IF(  .MOT.  status  )  CALL  LIB$SIGIAL(  XTAL(  status)  ) 


C - 

C  For  OABO:  -  BEQ  B  -  tbs  orrox  flag  -  go  to  digio.sxxox.ast 

C - 


dxb_flags.afnnm  »  0 
dxb.flags.svitohss  »  4 

status  °  ifSBQIO  (  ,  XTAL  (dxb.oban  ),  XTAL(  foods 
1  XTAL  (  dxb.f lags  .llagsoxd  ),  digio.sxxox.ast ,  ,  XvaKB)  ) 

IF(  .MOT.  status  )  CALL  LXB<SI6BAL(  XTAL(  status)  ) 


C - 

C  CoB^lStS  -  XStttXB  to  oallsx 

c - 


ISTDU 

BID 
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APPENDIX  E 


LIST  OF  BUS  ADDRESSES  IN  LOW  SPEED  WIND  TUNNEL 


c 


C  *•••••••••••*••••••••••••••  STl&T  OF  BtTS.AODBBSSBS  ••••••••> 

C - 

C  Dcliaitioa*  of  Data  icquisitiaa  Paxallal  Bna  addzassaa 

C  alloeatad  ia  LSVT  -  to  bo  inclndad  in  DI6I0.F0B 

C - 


ZITBGSX»2  addrosa.Ust  (0:1599) 


C - 

C  IddrosaoB  that  goaozato  apocial  avaata 

C - 


DlTl  addraaa.liat(O)  /  >0000>X  / 
DAT!  addzaaa.Uat(l)  /  >FFFF>Z  / 
DATA  addzaaa.llat(2)  /  >1>X  / 


>  lOP 

!  NASTBK  ASSET 
!  Triggaz  all  Kodnlaa 


C - 

C  Addzaaaaa  zalatiag  to  tha  Taaaal  Fazaaataz  Modala 

C - 


DATA 

addzaaa.liat (500) 

/ 

'8T70'X  / 

DATA 

addzaaa.liat (501) 

/ 

'8772 'X  / 

DATA 

addzaaa.liat (502) 

/ 

'8774'X  / 

DATA 

addzoaa.liat (503) 

/ 

'8776'!  / 

DATA 

addzaaa.liat (504) 

/ 

'8778'!  / 

DATA 

addzaaa.liat (SOS) 

/ 

'8T71'X  / 

DATA 

addzaaa. liat ( 506 ) 

/ 

'877F'X  / 

DATA 

addzaaa.liat (507) 

/ 

'877D'X  / 

DATA 

addzaaa.liat (508) 

/ 

'8783'X  / 

DATA 

addzaaa.liat ( S09) 

/ 

'8789'X  / 

DATA 

addzaaa.liat (510) 

/ 

'878F'X  / 

DATA 

addzaaa.liat (Sll) 

/ 

'8796'X  / 

DATA 

addraaa.liat ( S12) 

/ 

'8779‘X  / 

DATA 

addzaaa.liat (S13) 

/ 

'87A7'I  / 

DATA 

addzaaa.liat (514) 

/ 

'87A1'I  / 

DATA 

addzoaa.liat (SIS) 

/ 

'87AD'X  / 

DATA 

addzaaa.liat (516) 

/ 

'877B'X  / 

!  T  -  data  talaa  zoad 
!  M  -  data  talaa  zaad 
!  Dalta  P  -  data  zalao  zoad 
!  Pa  '  data  talaa  zaad 
!  T  -  data  valao  zaad 
!  So  -  data  ralaa  zaad 
!  T  aot  wzita 
!  M  aot  azito 

!  Cloaz  aczoaa  optiona  wzita 
!  Saatoz  coda  optioaa  wzita 
!  I.azgo  gzaphica  optioaa  wzita 
!  Saall  gzaphica  optioaa  wzita 
!  Aiz  toaq>ozataza  diaplay  wzita 
!  Faalt/aazrica  Maaaga  wzita 
!  Diaplay  Roaaago  (wzita) 

!  Vzito  iato  aaataz  Maaaga  baXfaz 
!  Load  Saa  So  zaf  loa  (wzita) 


C  Diaplajr  coatzol  coaMada 

DATA  addzaaa_Xiat(S20)  / 
DATA  addzaa8.11at(521)  / 
DATA  addzaaa_Uat(S22)  / 
DATA  addzaaa_Uat(S23)  / 
DATA  addzaaa_Uat(624)  / 
DATA  addraaa_liat(525)  / 
DATA  addzaaa_liat(526)  / 


•»7M'X/ 

>8795>X/ 

'8787'X/ 

»8789>X/ 

'878**X/ 

'878D'X/ 


•  Chaag#  diaplay  Moda 
!  Cloaz  display 
!  Cbaaga  backgzoaad  zaataz 
!  Saloct  lazgo  ehaz  diaplay 
!  Saloct  Mdiaa  chaz  diaplay 
!  Saloct  diaplay  oa  liaa  13 
!  Saloct  diaplay  oa  liaa  14  8  15 


C  aaa  Soad  data  ecawHada 

DATA  addzaao_Uat(530)  /  '8791 'X/ 
DATA  addzaa8.U8t(B31)  /  '8T93>X/ 
DATA  addzaoa.Uat(S32}  /  '8795>Z/ 
DATA  addzaaa.UBt(S33)  /  >8797'X/ 
DATA  addzaaa_Uat(S34)  /  >8799'X/ 
DATA  addzaaa.Uat(SS6)  /  '879B'Z/ 


!  Saad  Maaaga  tor  diaplay 
!  Soad  fizat  labal 
!  Saad  fizat  awabaz 
!  Saad  Boeoad  labal 
!  Soad  aacoad  awaboz 
!  Saad  third  labal 


Om  *ddraM_liat(536)  /  >879I>>X/ 


!  Sand  third  amnbaz 


DlTl  addEasa_liat(S40)  /  ’87F0’X/  !  Input  Coaf  ID  for  npdata 

Dili  addraaa_Uat(S41)  /  •87F1'X/  !  Hzita  Coaf  ID  for  iq>dnta 

DiTl  nddzaBa_liat(542)  /  ’87F2'I/  !  Input  Coaf  ID  for  raad 

DATA  addrass_list(B43)  /  >87F3*X/  !  Vzita  Coaf  ID  for  raad 

DATA  addrass_list(S44)  /  *87AC*X/  !  Band  Mnatar  Haasaga  bnffaz 

DATA  addrasB_list(S45)  /  ’87AD’X/  !  Hrita  Khataz  Massaga  bnffaz 

C  Addzasaas  zalatiag  to  tha  S6  aaplifiar  nodnla 

C  aaa  Data  Talna  raada  of  all  channals 

DATA  addzaaa.liatdOO)  /  ’8169’X  /  !  Tziggax  conzazsion  on  all  ADC’s 

DATA  addzaas_liat(101)  /  ’8iP4’X  /  !  Baad  ADC  conTozsion  bnffaz 

DATA  addzasa.list(103)  /  >8170>X  /  !  hand  ADC  channal  1 

DATA  addzasa_Iist(103)  /  ’8172’X  /  !  haad  ADC  channal  2 

DATA  addzass_liat(104)  /  >8174>X  /  !  Eaad  ADC  channal  3 

DATA  addrass_liat(10S)  /  ’8176’X  /  !  hand  ADC  channal  4 

DATA  addzasa_liat(106)  /  ’8178’X  /  !  Eaad  ADC  channal  S 

DATA  addrasa_Ust(107)  /  >817A>X  /  !  Eaad  ADC  channal  6 


C  aaa  Eoads  for  channals  in  pairs 

DATA  addrass_liat(108)  /  >8171>X  / 
DATA  addzass_Ust<i09)  /  ’SIDO’X  / 
DATA  addzass.UstdlO)  /  ’SITO’X  / 
DATA  addzass.Ustdll)  /  ’81D2>X  / 
DATA  addrass_liatdl3)  /  ’8172’Z  / 
DATA  addzass_listdl3)  /  >817S>Z  / 
DATA  addrsss.listdl4)  /  >81D4>Z  / 
DATA  addrass.liat(UE)  /  >8174’X  / 
DATA  addrass.liatdie)  /  ’81D6’X  / 
DATA  addzsss.Ust<U7)  /  ’B176>X  / 
DATA  addzoss.UstdlB)  /  >8177>X  / 
DATA  addrass_listdl9)  /  >81D8’X  / 
DATA  addzsss.UstdZO)  /  '8178'X  / 
DATA  addzsss.liatdai)  /  ’SIDA’X  / 
DATA  addrsss.liatd22)  /  >817A’X  / 


!  Triggar  Channals  1  E  2 
!  Eaad  ADC  channal  1  statns  bnffaz 
!  Eaad  Channal  1 

!  Eaad  ADC  channal  2  statns  bnffaz 
•  Eaad  Channal  2 
!  Triggar  Channals  3  E  4 
!  Eaad  ADC  channal  3  statns  bnffaz 
!  Eaad  Channal  3 

!  Eaad  ADC  channal  4  statns  bnffaz 
!  Eaad  Channal  4 
!  Tziggnz  Channals  5  E  6 
!  Eaad  ADC  channal  8  statns  bnffaz 
!  Eaad  Channal  6 

!  Eaad  ADC  channal  6  status  bnffaz 
!  Eaad  Channal  6 


C  aaa  Calibration  Ealay  Opazations 

DATA  addzass_listd23)  /  'BIFO’X  /  !  Eaad  calibration  rolay  statns 

DATA  addzoss.llstd24)  /  ’SlFl’X  /  !  Tnzn  Calibration  Ealay  >01’ 

DATA  addrass_liatd2S)  /  ’SlFl’X  /  !  Tnzn  Calibration  Ealay  ’OFF’ 

C  Addrossas  zalatiag  to  tha  ZnclinMsatar  laodnla 


DATA  addzasB.liat (ISO)  /  ’8A63’X  /  !  TZiggaz  convazaion  on  all  ADC 

DATA  addzass.UatdSl)  /  ’SATO’X  /  !  Eaad  ADC  1.  channal  1  -  X 

DATA  addzass_Ust(152)  /  ’8A72’X  /  •  Eaad  ADC  1,  channal  2  -  T 

DATA  addzasa.UatdSS)  /  ’SA74>X  /  !  Eaad  ADC  2.  channal  1  -  X 

DATA  addrasa.list(154)  /  ’8A7S>X  /  !  Eaad  ADC  2,  channal  2  -  tanp 

DATA  addzasa.UatdSS)  /  ’SATl’X  /  !  Tziggaz  ADC  1 

DATA  addzsaa.UatdS*)  /  >SA7S’Z  /  !  TZiggar  ADC  2 

DATA  addzaaa.liatdST)  /  ’UTS’X  /  I  Eaad  Eoll  aa  calcnlatad 
DATA  addzasa.UatdSS)  /  ’SATA'X  /  !  Eaad  Fitch  aa  aalcnlatad 

DATA  addzasa.UatdSS)  /  ’SATC’X  /  !  Eaad  raqairsd  EoU  Offaat 

DATA  addzasa.UatdSS)  /  ’SATl’X  /  !  Eaad  za^aizad  Fitch  Offset 
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w 


DAT! 

addxass.listdfil) 

/ 

>8A7D>X  / 

Vzita  Cal.  Boll  Offaat 

DATA 

■ddxaas.liat (162) 

/ 

'817P«1  / 

Vzita  Cal.  Pitch  Offaat 

DATA 

addxass.liat (163) 

/ 

>8AAfi>X  / 

Modal  Aligomaat 

DATA 

addr«sa_list (164) 

/ 

>8AAD>X  / 

Salact  Qflaz  Tzanadncaz 

C  Addzassas  xalatiag  to  th»  ActMtox  modnla 

c - 

- 

DATA 

addraaa.liat (800) 

/ 

’8B69>X  / 

1 

Tziggaz  ainltaaaoaa  aoza 

DATA 

addxaaa.liat (801 ) 

/ 

>8BD1>X  / 

1 

Haaaal  dziza  -  chaanal 

DATA 

ad6xaaa_liat(802) 

/ 

>8BD3>X  / 

• 

Kaaaal  dziza  -  aeza 

DATA 

«ddraaa_llat (803) 

/ 

>8BDB>X  / 

1 

Maanal  dziza  -  azit 

DATA 

addzaaa.liat (804) 

/ 

>8B66>X  / 

• 

Baad  ealibzatiOB  coaff . 

DATA 

addxaaa.liat (806) 

/ 

>8B60>X  / 

1 

Baad  azzoz  coda 

DATA 

addraaa_liat (806) 

/ 

>8B61>X  / 

1 

Baaat  azzoz  atatna 

DATA 

addzaaa.liat (80T) 

/ 

>8B6S>X  / 

• 

Claaz  atatoa/azzoz  half az 

DATA 

addzaaa.liat (808) 

/ 

>8B67>X  / 

1 

Claaz  azzoz  8  flag  bita 

DATA 

addzaaa.liat(809) 

/ 

>8BD0>X  / 

1 

Baad  Motoz  Statas  Bagiataz 

C  ghmuf  1 

1 

DATA 

addzaaa.liat (810) 

/ 

•8B70»X  / 

• 

L7DT  Baadiag  to  aaataz 

DATA 

addzaaa.liat (811) 

/ 

»8B71*X  / 

1 

Aaglo  to  Moza  to 

DATA 

addzaaa.liat (812) 

/ 

>8B72>X  / 

1 

CazTOBt  aagla 

DATA 

addzaaa.liat (813) 

/ 

»8B73»X  / 

1 

Sat  appaz  liait 

DATA 

addzaaa.liat (814) 

/ 

*8B74»X  / 

1 

Baad  appaz  limt 

DATA 

addzaaa_liat(816) 

/ 

•8B75'X  / 

( 

Sat  lozaz  lijiit 

DATA 

addzaaa.liat (816) 

/ 

>8B76'X  / 

1 

Baad  loaaz  liadt 

DATA 

addzaaa.liat (817) 

/ 

*8B77'X  1 

1 

Sat  Offaat  aagla 

C  diaanal 

2 

DATA 

addzaaa.liat (820) 

/ 

’8B78'X  / 

• 

ITDT  Baadiag  to  aastaz 

DATA 

addraaa.liat(821) 

/ 

>8B79>X  / 

1 

Aagla  to  Moza  to 

DATA 

addraaa.liat(822) 

/ 

>8B7A'X  / 

1 

Cazzaat  aagla 

DATA 

addzaaa.liat (823) 

/ 

’BBTB'X  / 

1 

Sat  ^vpaz  limit 

DATA 

addzaaa.liat (824) 

/ 

»8B7C'X  / 

• 

Baad  ^paz  limit 

DATA 

addzaaa.liat(825) 

/ 

'8B7D'X  / 

• 

Sat  loaaz  limit 

DATA 

addzaaa.liat (826) 

/ 

»8B7K»X  / 

1 

Baad  loaaz  limit 

DATA 

addzaaa.liat(827) 

/ 

'SBTF'X  / 

1 

Sat  Offaat  aagla 

C  •••  Chaual 

3 

DATA 

addzaaa_liat(830) 

/ 

'8B80’X  / 

• 

LTDT  Baadiag  to  maataz 

DATA 

addzaaa.liat (831) 

/ 

>8B81>X  / 

1 

Aagla  to  Moza  to 

DATA 

addzaaa.liat (832) 

/ 

'8B82’X  / 

1 

CazzoBt  aaglo 

DATA 

addzaaa.liat(833) 

/ 

>8B83’X  / 

• 

Sat  i9paz  limit 

DATA 

addzaaa.liat (834) 

/ 

’8B84*X  / 

1 

Baad  ^paz  liadt 

DATA 

addEaaa_liat(836) 

/ 

'8B86>X  / 

1 

Sat  loaaz  liadt 

DATA 

addzaaa.lijit(836) 

/ 

>8B86>X  / 

• 

Baad  loaaz  limit 

DATA 

addzaaa.liat (837) 

/ 

>8B87>X  / 

1 

Sat  Offaat  aagla 

C  •••  Cluuuial 

4 

DATA 

addra8a_li8t(840) 

/ 

*8B88'I  / 

1 

LTDT  Baadiag  ta  maataz 

DATA 

addraaa_liat(841) 

/ 

>8B89>X  / 

! 

Aagla  ta  Moza  to 

DATA 

addza8a_ll8t(842) 

/ 

*8B8A>X  / 

! 

CBzroBt  aagla 

DATA 

addzaaa.liat (843) 

/ 

>8D8B*X  / 

1 

Sat  appaz  limit 

DATA 

addzaaa.liat (844) 

/ 

>8B8C>X  / 

1 

Baad  ^^paz  limit 

DATA 

addraaa.liat(846) 

/ 

'8B8D'X  / 

f 

Sat  loaaz  limit 

DATA 

addzaaa.liat(848) 

/ 

•BB81>X  / 

! 

Baad  loaaz  limit 

DATA 

addzaaa.Uat(847) 

/ 

'8B8r>X  / 

! 

Sat  Offaat  aagla 

C  •••  CiM— 1  s 
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DATA  uddr^M.liitCABO)  /  ’8B90'X  / 
DATA  »ddr«»»_li»t(861)  /  'SBDl*!  / 
DATA  •ddr«M.Ust(8S3)  /  »8B92*X  / 
DATA  addraM.UstCSSa)  /  ’8B93’X  / 
DATA  •ddr*«»_li»t(864)  /  ’8B94'X  / 
data  addT«ss_llst(8BB)  /  ’8B9E’X  / 
DATA  addr«sa_U>t(856)  /  *8B96’X  / 
DATA  *ddr*««_li*t(8S7)  /  ’8B97’X  / 

C  •••  Chaanal  6 

DATA  addxaaa.liat(860)  1  >8B98>X  / 
DATA  addxaaa_liat(861)  /  *8B99'X  / 
DATA  addraaa_llat(882)  /  >8B9A’X  / 
DATA  addraaa_liat(883)  /  *8B9B’X  / 
DATA  addraaa_Uat(884)  /  >8B9C*X  / 
DATA  addraaa_Uat(885)  /  >8B9D'X  / 
DATA  addraaa_liat(86«)  /  ’8B9B‘X  / 
DATA  addraaa_Uat(887)  /  >8B9r>X  / 

C  Chaanal  7 

DATA  addraaa_Uat(870)  /  »8BA0‘X  / 
DATA  addraaa.Uat(871)  /  >8BA1*X  / 
DATA  addraaa_Uat(872)  /  '8BA2>X  / 
DATA  addraaa_Uat(873)  /  >8BA3>X  / 
DATA  addraaa_Uat(874)  /  •8BA4>I  / 
DATA  addraa8_liat(875)  /  *8BA6’X  / 
DATA  addiaaa_Ua«(876)  /  >8BA6>X  / 
DATA  addraaa_Uat(877)  /  *8BA7>X  / 

C  •••  Cban&al  8 

DATA  addraaa.Uat(880)  /  *8BA8>X  / 
DATA  ad^aaa.Ua«(881)  /  '8BA9'X  / 
DATA  BddraBa_Uat(882)  /  >8BAA*X  / 
DATA  addxaaa_liat(883)  /  'SBAB'X  / 
DATA  addraaa_li.at(884)  /  ’SBAC’X  / 
DATA  addraaa_Uat(885)  /  'SBAD’X  / 
DATA  addx8aa_liat(886)  /  '8BAE'X  ! 
DATA  addraaa.Uat(887)  /  >8BA7>X  / 

C  •••  Chaaaal  9 

DATA  addraaa_Uat(890)  /  'SBBO'X  / 
DATA  addraaa_Ua«(891)  /  'SBBl’X  / 
DATA  addraaa.liat(892}  /  ’SBB2’X  / 
DATA  addxaa8_liat(893)  /  '8BB3'X  / 
DATA  addxaaa_liat(894)  /  '8BB4>X  / 
DATA  addr8aa_llat(898)  /  ’SBBB’X  / 
DATA  addraaa_Ua«(8«8)  /  ’8BB8’X  / 
DATA  addraaa_Uat(897}  /  ’8BB7'X  / 


!  LTOT  gaading  to  Matar 
!  Aaglo  to  Koto  to 
!  Cnxxoat  angla 
!  Sot  i^por  limit 
!  Road  oppor  limit 
!  Sot  looor  limit 
!  Boad  looor  limit 
!  Sot  OXfaot  angla 


!  LTDT  Boadiag  to  maator 
!  Anglo  to  Koto  to 
!  CnzTont  aaglo 
!  Sot  i^poT  limit 
!  Baad  appar  liadt 
!  Sat  looor  limit 
!  Baad  looor  limit 
!  Sot  Offaot  aaglo 


!  LTDT  Bonding  to  maator 
■  Anglo  to  Koto  to 
!  Cnrrant  aaglo 
!  Sot  i^por  liadt 
!  Baad  i^por  limit 
!  Sot  looor  liadt 
!  Boad  looor  limit 
!  Sat  Oifaot  aaglo 


!  LTDT  Boadiag  to  maator 
!  Anglo  to  Koto  to 
!  Carrant  aaglo 
!  Sot  oppor  limit 
!  Baad  iq^pax  liadt 
!  Sot  looor  limit 
!  Baad  looor  limit 
!  Sot  OXTaot  aaglo 


!  LTDT  Bonding  to  maator 
!  Aaglo  to  Koto  to 
!  Coxraat  aaglo 
!  Sot  oppor  limit 
!  Boad  oppor  liadt 
!  Sot  looor  limit 
!  Bond  looor  liadt 
!  Sot  Offaot  aaglo 
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C  •••  Cliaiual  10 

DATA  «ddr*M_Ust(900)  / 
DATA  •ddz«M_list(901)  / 
DATA  «ddrMa_liLSt(902)  / 
DATA  •ddx«M_li.at(903)  / 
DATA  •ddxaaa_Ilat(904)  / 
DATA  a<Uxaaa_liat(905)  / 
DATA  addraaa_liat(906)  / 
DATA  addxaaa_Uat(907)  / 

C  •••  Cltaiiital  11 

DATA  addraaa.UatOlO)  / 
DATA  addraaa_liat(911)  / 
DATA  adAxaaa_llat(912)  / 
DATA  addraaa_liat(913)  / 
DATA  addzaaa_liatC914)  / 
DATA  addraaa.liat(915)  / 
DATA  addxaaa_liat(916)  / 
DATA  addTaaa_lxat(917)  / 


>8BBB>X  /  !  LTDT  Raadiag  to  aaataz 

<8BB9>X  /  !  Anglo  to  Mora  to 

>8BBA*X  /  !  Cazrant  angla 

’SBBB’X  /  !  Sot  i^pox  Unit 

>8BBC>X  /  !  Bond  ^por  liadt 

>8BBD>X  /  !  Sot  loBor  liiut 

>8BBB>X  /  !  Bond  loooz  liad.t 

>8BBF>X  /  !  Sot  OSSaot  anglo 


>8BC0’X  /  !  LTDT  Boading  to  aaator 

>8BC1’X  /  !  Anglo  to  Moto  to 

>8BC2'X  /  !  Cnzzont  anglo 

>8BC3>X  /  !  Sot  ^ipoz  lijd.t 

’8BC4*X  /  !  Boad  nppor  Unit 

>SBCS>X  /  !  Sat  loooz  limit 

>8BC6>X  /  !  Boad  loooz  limit 

>8BC7>X  /  !  Sat  Offaot  angla 


C  •••  Channal  12 


DATA 

addzaao_Uat(920)  / 

>8BC8>X  / 

• 

LTDT  Boading  to  maataz 

DATA 

addzaaa_llat(921)  / 

’8BC9>X  / 

1 

Angla  to  Koto  to 

DATA 

addzoao_Uat(922)  / 

>8BCA*X  / 

1 

Cnzzont  anglo 

DATA 

addzoaa_liat(923)  / 

>8BCB'X  / 

1 

Sat  nppoz  limit 

DATA 

addzaaa_liat(924)  / 

>8BCC>X  / 

t 

Boad  nppoz  limit 

DATA 

addzaaa.liat(925)  / 

>8BCD’X  / 

• 

Sot  loooz  limit 

DATA 

addzooa_liat(926)  / 

*8BCB’X  / 

1 

Boad  loooz  liadt 

DATA 

addzaaa_liat(927)  / 

*8BCF'X  / 

1 

Sat  Oifaat  anglo 

C  000  Aetnatoz  Calibzation  Coofficionta 

DATA  addraaa.llat(930}  /  *8BDB>X  /  !  Tnzn  Nannal  Pnlao  Kodo  01 

DATA  addzoaa_Uat(931)  /  ’8BDD*X  /  !  Tnzn  Nannal  Pnlao  Kodo  OFF 


C - 

C  ooooooooooooooaooooooooooa*  BID  OF  EOS_ADI»ESSBS  ••••••••ooooo. 
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APPENDIX  F 


LIST  OF  BUS  ADDRESSES  IN  VARIABLE  PRESSURE 
TRANSONIC  WIND  TUNNEL 


C  STltT  OF  BnS_iI»ttBSSES  ••••••••! 

C  Oafiaitions  oi  Data  Acquisition  Paxallal  Bus  addrassaa 

C  -  to  ba  incladad  in  OI6IO.FOR 


IBTE6EBa2  addxaaa_liat  (0:1599) 


C  iddxassaa  that  ganazata  spacial  arants 


DATA  addzasa_Ust(0)  /  >0000 >X  / 
DATA  addzaaa.Uatd)  /  >FFFF>X  / 
DATA  addrasa_list(2)  /  *1>X  / 


!  HOP 

!  NASTSK  KBSBT 
!  Tziggaz  all  Modnlas 


C - 

C  Addzaasat  zalatiag  to  tba  Tnaatl  Pazaaataz  Modulo 

C - 


DATA 

addrass.list (500) 

/ 

>8570>X  / 

DATA 

addrass_list(501) 

/ 

>8572>X  / 

DATA 

addross.list(502) 

/ 

>8574>I  / 

DATA 

addr oss.list ( 503) 

/ 

>8576>X  / 

DATA 

addross.list (504) 

/ 

>8678>X  / 

DATA 

addrass.list (505) 

/ 

>85TA>X  / 

DATA 

addross.list (506) 

/ 

>8571 >X  / 

DATA 

addross.list (507) 

/ 

>8573>X  / 

DATA 

addross.list (508) 

/ 

>8583’X  / 

DATA 

addross.list (509) 

/ 

>8585>X  / 

DATA 

addross.list (510) 

/ 

>8587>X  / 

DATA 

addross.list (511) 

/ 

>8589>X  / 

DATA 

addross.list (512) 

/ 

>858B>X  / 

DATA 

addross.list (513) 

/ 

>8595>X  / 

DATA 

addross.list (514) 

/ 

>858D>X  / 

DATA 

addross.list (515) 

/ 

>8591 >X  / 

DATA 

addross.list (516) 

/ 

>8575>X  / 

!  T  -  data  talno  zaad 
!  N  -  data  talna  road 
!  B  -  data  ralna  road 
!  P  -  data  talno  road 
!  T  -  data  ralna  road 
!  Aa  -  data  ralna  road 
!  T  oat  nrito 
!  H  not  nrito 

!  Cloar  acraaa  options  nrito 
!  Aastor  coda  options  nrito 
!  Largo  graphics  options  nrito 
!  Snail  graphics  options  nrito 
!  Air  tonparatnra  displaj  nrito 
!  Fanlt/sorrico  nassaga  nrito 
!  Display  Mossago  (nrito) 

!  Vrita  into  nastor  nassaga  bnffoz 
!  Load  Ran  Bo  rof  Ian  (nrito) 


C  aaa  Display  control  connaads 

DATA  addross_Ust(S20)  /  >85C9'X/ 
DATA  addrass_list(621)  /  >8583>X/ 
DATA  addrass_Ust(522)  /  >8585>X/ 
DATA  addraso_Ust(523)  /  >8687>X/ 
DATA  addzosa_Ust(524)  /  >8589 >X/ 
DATA  addrass_Ust(625)  /  >858B>X/ 
DATA  addzaos_Uot(528)  /  >858D>X/ 


!  Changa  display  Mods 
!  Cloar  display 
!  Changa  backgronnd  rastar 
!  Solact  largo  char  display 
!  Solact  nodinn  char  display 
!  Solact  display  on  lino  13 
!  Solact  display  on  lino  14  A  IS 


C  aaa  Sand  data  coanMnds 

DATA  addrass_list(630)  /  >8591 >X/ 
DATA  addrass_list(531)  /  >8B93>X/ 
DATA  addross_Ust(632)  /  '859S>X/ 
DATA  addrsss.llst(S33)  /  >8B97>X/ 
DATA  addraso_Ust(534)  /  >8599>X/ 


{  Sand  nassaga  Tor  display 
!  Sand  first  labal 
!  Sand  first  nnakar 
!  Sand  sacond  labal 
!  Sand  sacond  antbar 


DATA 

DATA 


addzass_Ust(535)  /  >SS9B>Z/ 
addr««>_llat(536)  /  >8S90>X/ 


!  Sand  third  labal 
!  Sand  third  nn^ax 


DATA 

DATA 

DATA 

DATA 

DATA 


addxaBS_UBt(540)  /  >856C>X/ 
addxasa_UBt(541)  /  >8S6D>X/ 
addxas8_Ust<542)  /  >856B>X/ 
addraaa_UBt(S43)  /  >866F’X/ 
«ddxa8a_liat(544)  /  >8590 >X/ 


!  Inpnt  Coaif  ID  lor  npdata 
!  tfrita  Coall  ID  lor  npdata 
!  Inpnt  Coall  ID  lor  road 
!  Vrita  Coall  ZD  lor  road 
!  Baad  Maatar  Maaaaga  Bnllar 


C  Addrosaaa  ralating  to  tha  S6  ai^Iiliax  aodnla 


C  aaa  Data  Talna  xaads  ol  all  chaanola 


DATA 

addraaa.liat (100) 

/ 

’8169’X 

/ 

Triggor  contaxaion 

on  all  ADC’a 

DATA 

addraaa.liatdOl) 

/ 

’81F4’X 

/ 

LOI 

1  bvflar 

DATA 

addrass.liat (102) 

/ 

’8170’X 

/ 

Kaad  ADC  channol 

1 

DATA 

addraaa.liat ( 103) 

/ 

’8172’X 

/ 

Kaad  ADC  channol 

2 

DATA 

addxosa_liat(104) 

/ 

>8174>X 

/ 

Kaad  ADC  channol 

3 

DATA 

addraaa.liat ( 105) 

/ 

>8176’X 

/ 

Kaad  ADC  channol 

4 

DATA 

addroaa.liat (106) 

/ 

>8178’X 

/ 

Kaad  ADC  channol 

5 

DATA 

addraaa.liat (107) 

/ 

’817A’X 

/ 

Kaad  ADC  channol 

6 

C  •••  Kaada  lor 

ehannala  in  paira 

DATA 

addxaaa.liat(108) 

/ 

>8171 >X 

/ 

• 

Triggor  Channola 

1 

A  2 

DATA 

addraaa_liat(i09) 

/ 

’81D0’X 

/ 

• 

Kaad  ADC  channol 

1 

atatna 

bnifax 

DATA 

addraaa.liat (110) 

/ 

’8170’X 

/ 

1 

Kaad  Channol  1 

DATA 

addxoaa.liat(lll) 

/ 

’81D2’X 

/ 

1 

Kaad  ADC  channol 

2 

atatna 

bnlfor 

DATA 

addroaa.liat ( 112) 

/ 

’8172’X 

/ 

1 

Kaad  Channol  2 

DATA 

addxaaa.liat (113) 

/ 

>8175>X 

/ 

1 

Triggar  Channola 

3 

k  4 

DATA 

addroaa.liat (114) 

/ 

>81D4’X 

/ 

1 

Kaad  ADC  channol 

3 

atatna 

bnffar 

DATA 

addxoaa.liatdlS) 

/ 

>8174’X 

/ 

• 

Kaad  Channol  3 

DATA 

addraaa.liatdlS) 

/ 

’81D6’X 

/ 

1 

Kaad  ADC  channol 

4 

atatna 

bnlfax 

DATA 

addroaa.liat (1 17 ) 

/ 

’8176’X 

/ 

• 

Kaad  Channol  4 

DATA 

addxaaa.liatdlS) 

/ 

’8177’X 

/ 

1 

Triggar  Channola 

5 

k  6 

DATA 

addroaa.liat ( 119) 

/ 

’81D8’X 

/ 

1 

Kaad  ADC  channol 

5 

atatna 

bnffoT 

DATA 

addroaa.liat (120) 

/ 

>8178’X 

/ 

1 

Kaad  Channol  5 

DATA 

addroaa.liat (121) 

/ 

’SIDA’X 

/ 

• 

Kaad  ADC  channol 

6 

atatna 

bnffar 

DATA 

addxaaa.liat (122) 

/ 

>817A’X 

/ 

1 

Kaad  Channol  6 

C  •••  Calibration  Kolay  Oparationa 

DATA  addraoa_Uat(123)  /  ’81F0’X  / 
DATA  addxos8_liat(134)  /  >81F1>X  / 
DATA  addross_Ust(125)  /  >81F1’X  / 


!  Bond  calibration  rolay  statna 
!  Tnm  Calibration  Kolay  ’OB’ 

!  Tnm  Calibration  Kolay  ’OFF’ 


- - 

C  iddxasBas  zalating  to  the  Scani.~Talve  modola 

- - 


Dm 

addzaas_liBt(300)  1 

>8361 >I  / 

!  Tziggar  data  acqniaition 

DATA 

addzaaB_liBt(301)  / 

*8364>X  / 

!  Raad  atatna  of  bnffar 

DATA 

addraaB_liBt(302)  / 

'836S>X  / 

!  Claaz  all  bnffazB 

DATA 

addraaa_liat(303)  / 

>836C>X  / 

!  Raad  oalactad  scaai-tralta 

DATA 

addzaas_liat(304)  / 

>8369'X  / 

!  Sat  poaaz  aattinga 

DATA 

addrasB_liBt(305)  / 

*836B>X  / 

!  Sat  opazation  noda  coda 

C  aaa  Calibration  Ralay  Oparationa 
DATA  addrass_list(308)  / 

•83P0>X  / 

!  Raad  calibration  rainy  atatna 

DATA 

addraBB_list(309)  / 

*83F1»X  / 

!  Toggla  Calibration  Rainy  OI/OFF 

C  •••  Triggaz  ADC  zaad  on  acaai-aalza 


DATA 

addzaaa_Uat(311)  /  >8371>X  / 

!  Road  Scani-aalaa  1 

DATA 

addroaB_liat(312)  /  >8373*1  / 

!  Raad  Scani-ralTo  2 

DATA 

addraBa_UBt(3i3)  /  >837S>X  / 

!  Raad  Scani-ralra  3 

DATA 

addraaa.UBt(314)  /  >8377>X  / 

!  Road  Scani-Talaa  4 

DATA 

addraaa.UatOlS)  /  >8379 >X  / 

!  Raad  Scani-ralTo  B 

DATA 

addraaB_liat(316)  /  >837B>X  / 

■  Raad  Scani-TalTO  6 

C  •**  Raad  ADC 

carda  of  all  channala 

DATA 

addraaa_Uat(321)  /  >8370 >X  / 

!  Road  Scani-TalTO  1 

DATA 

addraaa.liat(322)  /  >8372>X  / 

!  Raad  Scani-TalTo  2 

DATA 

addraBa_Uat(323)  /  >8374>X  / 

!  Raad  Scani-ralTO  3 

DATA 

addraa8_liBt(324)  /  >8376>X  / 

!  Raad  Scani-TalTO  4 

DATA 

addraaa.UBt(325)  /  >8378>X  / 

!  Raad  Scani-TalTO  S 

DATA 

addraaa_Uat(326)  /  >837A>X  / 

!  Road  Seani-TalTo  6 

C  **•  S«t  Aombcr  of  oolocto4  poirto  oa  ocaaiTolTo 

DATA 

addraaa.Uat(331)  /  >8391>X  / 

!  Scani-TalTO  1 

DATA 

addraaB.liat(332)  /  >8393>X  / 

!  Scani-ralTO  2 

DATA 

addraaa.UatOSS)  /  >8395*  I  / 

•  Scani-ralTO  3 

DATA 

addraaa.Uat(334)  /  >8397*1  / 

!  Scani-TalTO  4 

DATA 

addraaa.UBt(335)  /  >8399>X  / 

!  Scani-TalTO  5 

DATA 

addraaa_liat(336)  /  ’839B>X  / 

!  Scani-TalTO  6 

C  aaa  Raad  nnabar  of  aaloctad  porta  on  acaniTalaa 

DATA 

addraaa_UBt(341)  /  >8390>X  / 

!  Scani-ralTO  1 

DATA 

addraaa_Uat(342)  /  >8392>X  / 

■  Scaai-TalTO  2 

DATA 

addraaa.liat(343)  /  ’8394>X  / 

!  Scaai-TalTO  3 

DATA 

addraaa.UBt(344)  /  >8396>X  / 

■  Scani-TalTO  4 

DATA 

addraaa_liat(34S)  /  >8398>X  / 

!  Scani-ralTO  6 

DATA 

addraBa.Uat(346)  /  >S39A>X  / 

!  Scani'TalTO  6 

C  aaa  Sat  tha 

cnrrantly  aalactad  port  on  acaniTalTo 

DATA 

addraaa.Uat(361)  /  >839D>X  / 

!  Scani-ralTO  1 

DATA 

addroaa_Uat(3B2)  /  >839F>X  / 

!  Scaai-TalTO  2 

DATA 

addroaa_Uat(363)  /  '83A1>X  / 

!  Scani-TalTO  3 

DATA 

addraaa.Uat(364)  /  >83A3>X  / 

!  Scani-ralTo  4 

DATA 

addroaa_liat(35S)  /  >83AS>X  ! 

!  Scani-TalTO  5 

DATA 

addraaa.UstOSe)  /  >83A7>X  / 

!  Scani-ralTo  6 

C  aaa  Raad  tha  cnrrantly  aalactad  port  on  acaniTalTo 

DATA 

addroaa_llat(361)  /  >839C>X  / 

!  Scani-ralTo  1 

DATA 

addroas.Uat(3«2)  /  >839B>Z  / 

1  Scani'TalTO  2 

DATA 

addraaa_Uat(9C3)  /  'SSAO'X  / 

!  Scani-ralTo  3 

DATA 

addzaaa_Uat(3«4)  /  >S3A2>X  / 

!  Scani-ralTO  4 

DATA 

addraaa_Uat(3d6)  /  'tSAA'Z  / 

!  Scani-ralTO  B 

DATA 

addraaa.UatCSM)  /  >83A«>Z  / 

!  Scani-ralTo  4 
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i 

I 

I 


C  **•  S«t  tha 

••ttling  tioM  TLft*d  on 

scaniTalTs 

(in  ms) 

DATA 

addxaBB.liat (371 ^ 

/ 

*83A9’X  / 

Scani-TalTS  1 

DATA 

addraBs.liBt (372) 

/ 

•83AB>I  / 

Scaai-Talaa  2 

DATA 

addraBB.liBt (373) 

/ 

»83AD’I  / 

Seani-ralTS  3 

DATA 

addxaBB.liat (374) 

/ 

>83AF*I  / 

Scani-'TalTB  4 

DATA 

BddxaBa_liBt(375) 

/ 

>83B1>X  / 

Scani-TalTB  6 

DATA 

addraBB.Uat  (376) 

/ 

>83B3>X  / 

Scaai-ralva  6 

C  •••  Raad  th« 

1  aattlisg  tima  naad 

on  seaniTalva 

DATA 

Bddxaas.liBt (381) 

/ 

>83A8>X  / 

Scani-TalTS  1 

DATA 

addrasB. list (382) 

/ 

>83AA>X  / 

Seani-ralTB  2 

DATA 

addrasa.list (383) 

/ 

>83AC>X  / 

Seani-TalTs  3 

DATA 

addxass .list ( 384) 

/ 

>83JS>X  / 

Scani-ralTa  4 

DATA 

addrasB.list (386) 

/ 

>83B0>X  / 

Scaai-TalTs  5 

DATA 

addxass.list (386) 

/ 

>83B2>X  / 

Scani-TalTS  6 

c  ••••••••••••••«••*•••*«••••  ESD  OP  BUS.iDDBESSSS 

C - 
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Slave  Module  1  Slave  Module  2  •••  Slave  Module  n 


Figure  1:  Configuration  of  the  Wind  Tunnel  Data  Acquisition  System. 
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Figure  2:  The  word  format  of  DRVl  1  Control  Status  Register. 
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